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ABSTRACT 


The U.S. Coast Guard has been continuously asked to perform 
more missions with less resources. Technological advances in 
telecommunications and information systems accessibility have played a 
major role in the Coast Guard meeting these challenges. However, to 
meet new demands for even greater efficiency and effectiveness, the 
Coast Guard strategy for tighter interoperability between Coast Guard 
commands must continue to evolve. To support this evolution, the 
Command, Control, and Communication Branch of the Coast Guard 
must use a strategy for project management that will foster greater 
efficiency and effectiveness. This strategy should include a standardized 
approach to project management that fosters communication, attention 
to detail, and leads to interoperability of systems through 
standardization without extensively limiting creativity or use of 
technological advances. 

This paper demonstrates how the use of systems thinking, and in 
particular the Structured Approach Model, can encourage the 
management characteristics that will lead to the development of more 
effective telecommunications projects and completion of those projects in 
a more efficient manner. This paper explains the seven phases of the 
Structured Approach Model and views each using the functional, 
organizational, and physical prospectives. Steps for applying the model 


are given and are aimed at the Coast Guard project officer. 
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I. INTRODUCTION 


A. PURPOSE 

The purpose of this thesis is to outline a structured approach to 
assist US Coast Guard project officers in developing and planning a 
major telecommunications system replacement project. This 
methodology will provide processes to support the project officer in 
soliciting, documenting, and tracking project requirements using a 
“systems approach.” This thesis will develop methods for completing a 
baseline assessment, developing a target architecture, and selecting a 
migration path from available alternative technologies. The selection 
process will include a cost-effectiveness analysis. 

The replacement project for the Coast Guard’s Bay Area 
Communications System (BACS) in the San Francisco area will be used 
to illustrate the application of this methodology. Where actual data is 
not available, assumptions (or estimates) will be used for the express 
purpose of illustrating the methodology. 

The purpose of this thesis is NOT to recommend a particular 
alternative for the BACS replacement project. The purpose is to provide a 
methodology that encourages project officers to plan and develop their 
projects using a systems view and provide a number of processes and 
procedures they can use in doing so. 

The primary research questions for this thesis included: 


1. How can the structured approach model be used to ensure all 
aspects of the project are considered? 


2. How can the existing functional requirements and any new 
functional requirements expected to arise over the new system’s 
life-cycle be gathered and documented? 


3. How can we track the functional requirements for each site, the 
physical capacities for each site, and the technological 
alternatives that can most effectively meet these constraints? 


4. Once the alternatives for each site have been documented, how 
can we choose the most cost effective alternative? 


a) What criteria should be used to select the alternatives? 


b) How should the chosen criteria be weighted for 
comparison? 


c) Who should develop the criteria weights? 
5S. What types of resistance to change may arise? 


6. What can be done to overcome resistance to change? 


B. DISCUSSION 

We live in an era of very complex technologies and system 
interdependencies. To cover all the bases, a project officer must consider 
a project from many different aspects. Applying an existing list of project 
considerations is not sufficient, for every project is unique in some 
manner. A solution rests in the use of “systems thinking” concepts and 
applying a model that provides an analytical framework on which project 
officers can build their own list of considerations. The structured 
approach model provides such a framework for managing a project from 
conception of customer goals to maintaining the system after 
installation. This thesis will focus on the planning and development 
stages of the structured approach model. 

A Coast Guard project officer for a telecommunications project has 
even more complex job than most other project officers. 
Telecommunications are a part of our basic infrastructure. Changes to 
the infrastructure affect many different entities, including those in both 
operational and support roles; therefore, changes to the infrastructure 


should be undertaken as infrequently as possible. For this to occur, the 


infrastructure must be designed to meet the users’ needs today and be 
designed to migrate to meet future needs, with as little disruption to the 
user as possible. 

This takes proper planning and a great deal of knowledge, 
cooperation, and coordination. The user understands what must be 
done to complete the missions, but the project officer is the technical 
expert. The user must help the project officer understand every process 
used to complete the mission. The project officer must educate the user 
as to how technology can help him more effectively complete the mission. 
Together, they must paint a picture of the users systems, as they exist 
today, and how they may change in the future. This evaluation of the 
users systems must all take place before any changes to the supporting 
telecommunications system can even be considered. In other words, how 
can the project officer design a supporting infrastructure if it is not 
understood what needs to be supported? 

This thesis steps through the phases of the structured approach 
model only once. But it should be understood that a minimum of two 
iterations of this model should be completed: once to cover the users 
systems that ride on the telecommunications system and once for the 
telecommunications system itself. 

The Bay Area Communications System (BACS) replacement project 
is an optimal project for illustration purposes. It contains most of the 
challenges faced when replacing a major telecommunications system. It 
spans some 25 sites spread over hundreds of miles and is located in both 
urban and rural areas. It has at least 12 customer commands, 
sponsored by numerous headquarters’ and pacific area entities. Site 
signal demands run the gamut from a few analog signals to multiple T- 


1’s. 


Cc. BACKGROUND 

The Coast Guard first installed the Bay Area Communications 
Microwave System between 1985-1987. This system connected 20 
different sites using 19 analog microwave links. It was designed to meet 
the Coast Guard wide area networking (WAN) needs, within the San 
Francisco area, that existed at the time. The reasons the Coast Guard 
cited when justifying the construction of the BACS system [Ref. 1, p. 80] 
were to: 


1. improve reliability and transmission quality for voice and data 
telephone circuits within the San Francisco Bay area; 


2. provide all the commands ("units") subordinate to USCG Group 
San Francisco with the capability to directly communicate with 
ships, boats, aircraft, and personnel throughout the bay area; 


3. provide an alternate routing to deliver textual message traffic 
between the communications station at Point Reyes, and the 
district office; 


4. replace existing UHF links between the communications station 
at Point Reyes and the communications center at Coast Guard 
Island, Alameda; 


5. replace existing UHF links between the transmitter and receiver 
sites at the communications station; 


6. reduce FTS (Federal Telephone System) and commercial 
telephone system recurring costs; 


7. provide FTS access to all bay area units; 


8. significantly improve communications in the bay area at a lower 
total life-cycle cost; 


9. provide AUTOVON access at a lower cost. 


As the Coast Guard WAN requirements have changed over the past 
decade, at least six major leased lines have been added to the system 
and one microwave link has been removed. The system is now referred to 


as BACS and connects 25 different sites. Appendix A contains a chart 


depicting the geographic location and inter-connection of the sites served 
by this system. The BACS interconnects at least 12 different Coast 
Guard units which have mission-related communications requirements. 

The Bay Area Communications System must be replaced for three 
reasons[Ref.2: p. 2]: 


1. the microwave links were built in the mid 1980’s and are 
becoming expensive to maintain; 


2. the frequency allocations for the 2 GHz microwave are to be 
reallocated to meet growing civilian frequency needs; 


3. customer requirements have changed and are no longer being 
met by the existing system. 


II. SYSTEMS THINKING AND 
THE STRUCTURED APPROACH MODEL 


A. SYSTEMS THINKING 


1. Introduction 
Systems thinking has been evolving over the course of the 
twentieth century and is used in fields as diverse as physical and social 
sciences, engineering, and management|Ref. 6, p. 68]. Over this period, 
countless tools and techniques have been developed. Therefore, the 
scope of this chapter must be limited to presenting the reader with a 
broad picture of “systems thinking.” The intention of this chapter is to: 
1. emphasize to the reader the importance of practicing systems 
thinking; 
2. assist the reader in understanding some of the basic principles 
of systems thinking; 


3. generate enough interest that the reader will perform further 
independent study of the principles of systems thinking. For 
highly recommended reading material on the subject of systems 
thinking, see Ref. 3. and Ref. 6. 


2. What is Systems Thinking? 

To understand systems thinking, we must first define a system. 
The Webster’s dictionary [Ref. 4, p. 1199] defines a system as, “A 
regularly interacting or interdependent group of items forming a unified 
whole. Our world is made up of systems. As these systems interact, they 
create an even larger, more complex, system.” For example, the BACS 
system consists of a microwave system and leased lines which interact 
together [Ref. 5, p. 1-1]. BACS can also be viewed as part of the Coast 


Guard telecommunications system used to communicate with internal 
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and external entities. Viewed in this context, the scope for designing an 
efficient system greatly increases in both detail complexity and dynamic 
complexity. Detail complexity exists when many variables must be 
considered. Dynamic complexity exists when any of the following occur 
[Ref. 6, p. 71]: 


1. when the same action has dramatically different effects in the 
short run compared to the long; 


2. when an action has one set of consequences locally and a very 
different set of consequences in another part of the system; 


3. when obvious interventions produce nonobvious consequences. 


Systems thinking is basically the art of understanding how system 
entities interact. Peter Senge [Ref. 6, p. 6|defines system thinking as: 
“a discipline for seeing wholes. It is a framework for seeing 
interrelationships rather than things, for seeing patterns of change rather than 
static “snapshots.” It is a set of general principles...a discipline for seeing the 


“structures” that underlie complex situations, and for discerning high from low 
leverage change.” 


Systems thinking consists of principles and practices. The 
principles help us to understand the basic causes for resistance to 
change within a system. The practices, or tools, help us to understand 
the dynamics at work within a system and find leverage points that can 


bring about change. 


3. How Can it Help the Coast Guard? 

The Coast Guard is structured, in a hierarchical manner, like 
many other bureaucratic institutions, with commands, divisions, 
branches, and so on. Each with specific areas of responsibility and 
expertise. This, however, tends to lead to a kind of assembly line 
mindset. We take what is given to us, apply our expertise, and hand it 


off to the next one in line. This is done with very little forethought of how 


our actions affect the actions, and work, of others. We rarely feel that we 
can bring changes to “the system,” so we continue doing our part and 


blame the rest of the system for existing inefficiencies. 


For example, suppose that a leased line is required for a new 
system. The project officer requests the line, the telecommunications 
officer orders the line, and the financial officer pays it. However, there is 
no mechanism to tract the leased line through its life-cycle. The 
Maintenance & Logistics Center (MLC) continues to pay for the line as 
long as it appears on the phone bill. In one instance Maintenance & 
Logistics Center Pacific (MLCP) found, by chance, that they had been 
continuously paying for four leased lines that had been disconnected six 
months earlier [Ref. 7]. In this example, each person did his job as 
assigned, but the system was not taken into consideration. When we 
look from each perspective view point, everything seems fine; but when 
looking at the system as a whole, and the outcome, it is obvious that the 


system needs fixing. 


4. Who Should Apply it? 

As leaders in the CG, we must encourage everyone associated with 
the CG to practice systems thinking. We must take the time to evaluate 
the ideas and issues that are raised, independent of who raises them. 

Programs such as Ideas Express are great motivational tools to 
encourage the raising of ideas. Additional programs which may raise the 
level of systems thinking should be carefully considered; however, 
nothing will work better than a boss willing to take the time to listen and 


evaluate. 


5. Conclusion 

The purpose of this section is to encourage others to independently 
study and apply systems thinking. In these times of shrinking budgets, 
systems thinking is essential if we are to reach the levels of efficiency and 


effectiveness demanded of us. 


B. STRUCTURED APPROACH MODEL 


1. Introduction 

Any large design project has many engineering and management 
considerations which must be tracked in a project file as the project 
moves forward. This involves both detail complexity and dynamic 
complexity. The procedures used in this paper are organized using the 
structured approach model as seen in Figure 1. The structured 
approach model assists the design team by organizing the major phases 
to be completed over the system’s life-cycle. This aids in tracking project 
details that have been examined. The model encourages the design team 
to look at the system from different perspectives. These perspectives form 
the framework for viewing the project in a “systems thinking” manner. 
This encourages the design team to consider the whole system during 


each project phase. 


2. The Structured Approach Model 

The model consists of eight phases (exterior) and three perspectives 
(interior). The model breaks the project’s life-cycle into eight phases, 
starting with “organize and plan” and finishing with “maintain system 
process.” Each phase is viewed using the three perspectives: 1) 
Functional, 2) Organizational, and 3) Physical. Following is a general 


definition of each of these perspectives, or views [Ref. 2, Module 2]: 
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Functional: The Functional perspective helps systems engineers and managers 
understand systems by examining and describing the functions that systems must perform 
to meet system requirements. 


Organizational: The Organizational perspective helps systems engineers and managers 
understand systems by examining and describing the configuration and the coordination 
required for systems to function effectively and efficiently. 


Physical: The Physical perspective helps systems engineers and managers understand 
systems by examining and describing the physical resources required by systems to 
perform their functions. 


Define 
System 
Problem 


Maintain Functional Assess 
System Baseline 
Process System 


Determine 


Organizational Physical Target 
System 


Select Develop 
Migration Migration 
Path Candidates 





Figure 1: Structured Approach Model; Framework (interior), Phases (exterior) 


The structured approach model is based on the model 


recommended in Volume four of the Department of Defense Technical 


Architecture Framework of Information Management (TAFIM}, 
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Architecture Concepts and Design Guidance. The TAFIM model differs 
from the structured approach model by breaking the project into seven 
phases, instead of eight, and does not take advantage of the perspective 
framework (interior). In the author’s opinion, the inclusion of the 
perspective framework is the distinct advantage of the structured 
approach model. It requires the design team to consider the whole 


system during each phase of the project. 


3. How Can it Help the Coast Guard? 

Two major problems faced by project officers when dealing with 
large projects include 1) justifying the decisions made by the design 
team, and 2) historically recording these decisions and the reasoning 
behind them. Large projects normally last for years, from conception to 
completion. Due to military rotations and other factors, personnel 
turnovers can occur in both the design team and the 
reviewing/approving hierarchy. With these turnovers, information 
pertaining to the decisions made may be lost if not documented properly. 

Following the model, the project officer should record in the project 
folder all the information considered by the design team for each 
perspective, during each phase. This record can be instrumental in the 
following ways: 

1. it can assist the approving officers in understanding the 

reasoning behind the design team decisions; 


2. it will allow entities outside of the design team to raise 
concerns, or suggest alternatives, not considered by the design 
team; 


3. it will help replacement personnel quickly visualize the project's 
history, see where the project stands, and comprehend why the 
project has taken the path it has. 
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Coast Guard voice and data telecommunications requirements will 
constantly change as technology evolves and mission, equipment, and 
software application requirements change. Therefore, the 
telecommunications system must also evolve to meet these requirements. 
By following the structured approach model, a migration plan to meet 
these changing requirements will already exist; however, design teams 
can only forecast the future with some inevitable uncertainty. As the 
future becomes more clear, the network manager may have to request 
adjustments to the migration plan to match the actual environment. A 
well-documented migration plan provides an historical baseline the 
network manager can use to compare the evolving organization, 
functional requirements, and available technologies with those forecast 
by the design team. The justification for requested changes will be 
established much more readily by using a comparison to the well- 


documented baseline than by starting from scratch. The example in 


Figure 2 illustrates the usefulness of such documentation. 











1996: Imagine This... 


In the approved plan, the BACS design team has chosen microwave 
as the optimal technology for the Mount Umunhum remote site. To back up 
the essential voice circuits, in the event of a microwave system failure, a 
standby cellular-based system was chosen over a Satellite-based system due 
|to estimated costs (cellular: $100/mo., satellite: $150/mo.). 

It is now 1999... 


The cellular-based system has worked fine, but the actual costs have 
averaged $125/mo. The network manager does some research and learns 
that, with the Teledesic and Iridium satellite systems operational since 
1998, monthly costs for a satellite-based system have dropped to $100/mo. 
and would provide twice the data rate of the cellular service. This would 
allow the new CGXV data circuit to be backed up, in addition to the voice 
circuits. 


From the BACS project folder, the network manager has available all 
the considerations and estimates used by the design team to justify the 
cellular system. He can readily make a comparison detailing the changes in 
environmental factors to justify switching to a satellite-based system. 





Figure 2: Illustration of Documentation Effectiveness 


4. Conclusion 

The structured approach model assists the design team by 
providing a framework for organizing the major phases of a large 
engineering project. It encourages the use of systems thinking by 
providing a method to document project decisions and the reasoning 
behind them. The documentation will help those outside the decision 
process to quickly comprehend the project history and the justification 


used for the path taken. 
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III. STRUCTURED APPROACH PROCESS: 
PHASES | & Il 


A. INTRODUCTION 

The structured approach model can be used at a variety of 
strategic and planning levels. This chapter will briefly discuss the Coast 
Guard enterprise-wide level, then outline the phases at a project 
officer/design team level. Although they will normally consist of two 
separate groups, in this paper the terms “design team” and “Architecture 


Work Group (AWG)” will be used interchangeably. 


B. ENTERPRISE-WIDE STRATEGY 

Any project considered by the MLC or HQ unit “t” divisions should 
correspond, in some manner, to the strategy outlined in the objectives, 
strategies, and goals established by the Commandant (this includes the 
program offices). In the Office of Command, Control, & Communications 
(G-T), strategy is established by the Board of Directors. 

Phases I & II are the strategic and system planning phases. Phase 
I should be completed at the Headquarters level, using the corporate 
objectives and vision, to build a framework for the Coast Guard’s overall 
IT architecture. Unfortunately, the Coast Guard does not have a well- 
defined process to gather the IT requirements of the twelve Coast Guard 
programs (Acquisition(A), Engineering & Development(E), etc.) into an 
integrated architecture. At this time, Headquarters also lacks the 


coordination to promulgate a set of standards that can accommodate the 


various program requirements. Although not currently incorporated by 





HQ, the Strategic Approach Model could be of great benefit; they could 


use it to outline: 


1. 
2. 


the missions and goals of each HQ office (organizational view); 


the functional requirements necessary to meet those goals; 


. the work processes necessary to meet the functional 


requirements; 


the high-level standards for applications, data definitions, 
information platforms, and a telecommunications infrastructure 
that will lead us in the direction of an integrated target 
architecture; 


. a migration plan to combine stovepipe IT systems supported by 


individual programs into an integrated Coast Guard IT system 
serving all program requirements. 


The Maintenance & Logistic Center’s Command, Control, & 


Communications Budget & Planning Division, MLC(tb), should use this 


high-level framework to define the problem(s) the project will confront 


and justify the direction the project will take. This could include, but not 


be limited to: 


ds 
2. 


combining requirements of various entities into larger projects; 


ranking projects to meet priorities as outlined by HQ’s strategic 
business plan; 


. the designing and implementation of projects to enable Coast 


Guard entities to meet the strategic objectives, as set forth by 


HQ. 


In the event that the strategic business plan is not outlined by 


their superiors, the project officer must react proactively. Through 


personal inquiries, the project officer should attempt to ascertain 


whether the project can incorporate unlisted CG objectives, in addition to 


the objectives listed in the planning proposal. No project stands alone; 


its location within the Coast Guard C3 infrastructure must also be 


accounted for in this phase [Ref. 13, p. 22]. 
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C. PHASE | FOR THE PROJECT OFFICER 

The first phase in the Structured Approach Process is the 
“Organizing and Planning” phase. The purpose of this phase is to 
develop an initial plan for the process of engineering and managing a 
system over time. This phase in the systems engineering and 
management process lays the groundwork for the planning and actions 
that occur throughout the Structured Approach Process. [Ref. 8, Ch. 6, 
and Appendix J] 

This phase will set the direction for the rest of the project to follow. 


The final products from this phase include: 


1. initial Executive Guidance; 
2. the PURPOSE of the system-in-focus; 


3. a VISION for the desired system end-state that accomplishes 
the PURPOSE; 


4. an initial PLAN for achieving the VISION; 
5. initial Executive Approval and Support. [Ref. 9, p. M3-6] 


1. Organizational View 

Some of the high-level Mission/Vision strategic drivers for the 
BACS begin with the Commandant’s Direction[Ref. 10]; in particular, 
Goal #8 states, “Pursue and exploit new technologies to achieve gains in 
productivity and enhance mission performance.” The objectives outlined 


to meet this goal include: 


1. redirect efforts in Research and Development to further mission 
productivity; 


2. use technology to enhance maritime safety, surveillance and 
environmental systems; 


3. be a partner with DOT’s R&D efforts to develop integrated smart 
transportation and navigation information systems; 


4. manage Coast Guard information resources. 
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Each Coast Guard program that inputs or uses data (or communications) 
carried on the BACS will have requirements which must be considered 
when developing an infrastructure system such as BACS. The timeframe 
for meeting the goals set by the Mission/Vision strategic drivers must 


also be derived. 


2. The Enterprise Tasks and Missions 

The goals of an enterprise are performance-based. In other words, 
“how do we want to perform our tasks, and the missions that drive those 
tasks.” This can be seen in the wording of the Commandant’s goals; 
these words include, “redirect,” “use,” “be,” and ”manage.” 

Headquarters sets the Coast Guard-wide goals, but Congress 
assigns us our missions. The Coast Guard's response to numerous 
mission requirements can be modeled as a recursive process involving 
the Coast Guard and Congress. The impact trickles down to BACS. 
Figure 3 illustrates the relationship between the mission-driven 
organizational architecture, the generation of new missions, and the 
requests for resources to meet the new responsibilities. 

The Coast Guard's San Francisco Bay area enterprise reflects the 
results of an evolutionary layering-on of missions. These missions are 
correspondingly reflected in the functionality of the BACS. The Coast 
Guard has adopted the policy that the small size of the service dictates 
that these missions be executed by small, multi-mission units. Each 
unit carries out multiple tasks, simultaneously or nearly simultaneously, 
on behalf of separate managers of the various program areas. BACS 
supports a similarly broad subset of all Coast Guard missions. The 
external Coast Guard missions BACS routinely supports can be classified 
in the following categories: 


1. Waterways Management seeks to develop, implement, and 
manage vessel traffic movements in congested or high-risk U.S. 
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waters. Implicit in this definition is the U.S. declared limit of 
three nautical miles for its territorial sea. The three nautical 
mile limit bounds the system in focus from a strictly 
constructed legal perspective. However, as a matter of 
practicality, customs laws and the military concept of a 
commander's understanding of the relationship between time 
and space conspire to extend this bound to the inshore horizon. 
The waterways management area of operations is analogous to 
the concept of battlespace developed in the Marine Corps' 
“Command and Control, FMFM 3.” 


Authority is exercised in the waterways management 
mission through promulgation of federal regulations which are 
either short-lived locally-generated regulations or standing 
federal regulations. Personnel and a network of sensor 
equipment also form the Vessel Traffic System (VTS). The VTS 
continuously monitors certain vessel movements, with the aim 
of preventing collisions between participating vessels. 


. Recreational Boating Safety aims to reduce the risk of injury, 
loss of life, and property damage associated with the use of 
pleasure craft in U.S. waters. In addition to numerous other 
administrative components of the program, the BACS- 
applicable portion concerns command and control functions 
exercised over the volunteers of the Coast Guard Auxiliary. 
These auxiliarists volunteer their time and facilities to 
conduct intermittent search and rescue patrols. When engaged 
in those activities, their boats and aircraft require a 
commensurate level of command and control, flight-following, 
and communications resources. The requirements are met by 
Group San Francisco, or a subordinate unit, using the 
communications capabilities inherent in BACS. 
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Figure 3: BACS/ Missions/ Resources Illustration 
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3. Maritime Law Enforcement concerns itself with enforcing all 
applicable federal laws through inspections, interdiction, and 
searches. The interdiction mission is supported by a large 
resource-intensive operational effort, and an all-source 
intelligence effort. Both these elements are major requirements 
drivers for BACS. 

The law enforcement "battle space” extends globally in the 
intelligence collection and reporting mission, and operationally 
with regard to jurisdiction over U.S. flagged vessels. 

The law enforcement mission is also characterized by a 
requirement for a high degree of interoperability with other 
agencies and military forces. Since the late 1980s’ several DOD 
Joint Task Forces have been continuously expending resources 
in counter-narcotics interdiction operations with the Coast 
Guard, adding their interoperability requirements to those of 
the many federal law enforcement agencies. 


4. Search and Rescue includes the planning and execution of 
resource-intensive missions to locate and recover people and 
property at sea and along the shore. Some of the associated 
information systems supporting the search and rescue mission 
are at the highest end of the Coast Guard's range of information 
systems complexity. For example, the Coast Guard Data 
Network component of BACS supports a mainframe-based 
simulation software product which predicts wind and current- 
induced drift that a shipwrecked survivor or disabled vessel will 
experience at sea. This in turn permits the allocation of 
resource effort to search in the areas of highest probability of 
detection. BACS is again called upon to disseminate the results 
of the search planning. 


5. Aids to Navigation is a mission composed of several distinct 
elements. Short-range aids include lighthouses, floating buoys, 
and fixed structures located on or near the water. Some of 
these devices are monitored via an electronic Automated 
Control and Monitoring System (AMSC). BACS supports the 
mission by transporting status reports on the associated lights, 
signaling devices, and electric generators. 

Long-range aids to navigation are based on several 
different forms of radio-navigation. The Coast Guard also 
publishes voice and textual reports informing mariners of 
hazards and other safety and marine navigation issues for 
waters in and near the United States. BACS supports the 
dissemination of this information and the management of the 


21 





entire program, and facilitates the collection of a useful series of 
performance metrics. 


6. Marine Environmental Protection exists to both prevent and 
minimize damage to the ecological and economic systems of 
U.S. ports, waterways, and coastal areas caused by pollution. 
The mission involves searching for and reporting oil spills, the 
management of cleanup operations, and the dispersing of vast 
sums of money for cleanup operations. These responsibilities 
are carried out by the Captain of the Port through the personnel 
of the Marine Safety Offices and Marine Safety Detachments. 


3. Functional View 


The next question is, “what functional requirements are necessary 


to meet the strategic drivers.” These will include requirements such as: 


1. reliability requirements; 

2. security requirements; 

3. types and sizes of signals to be carried; 
4 


. signal timeliness (delay). 


To “manage Coast Guard information resources,” the requirements 
should include minimizing maintenance and network manager 
requirements. Therefore, any new system should include self-monitoring 
and diagnosing capabilities to a certain component level. To minimize 
network management, automatic re-routing (upon system failure) and 


automatic re-initialization (upon system repair) should be required. 


4. Physical View 

We must now address any high-level issues that will affect the 
telecommunications architecture. These issues will include any 
promulgated standards for telecommunications systems and any existing 
policies or instructions that could affect the project design. The issues of 


environment and technology availability must also be considered. 
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D. PHASE Ii FOR THE PROJECT OFFICER 

Phase II in the Structured Approach Process is the “Define System 
Problem” phase. The purpose of this phase is to structure the system 
problem so that all subsequent engineering and management efforts will 
be both effective (doing the nght thing) and efficient (doing things right). 
This phase in the systems engineering and management process bounds 
the problem and enables systems engineers and managers to focus on 
the most important issues and problems....[Ref. 11, p. M3B-1]. The basic 
product of this phase should include the Tentative Operational 
Requirement (TOR) paper. 


1. Organizational View 

Using the organizational view, we need to answer the question, 
“Organizationally, what cannot occur without the telecommunications 
project?” These deficiencies can be developed by comparing the strategic 
drivers to the capabilities of the existing system. Some of the possible 
strategic drivers could include, but are not limited to, the following: 

1. relocation, or reallocation of resources; 

2. joint operations with other units and/or organizations; 

3. change in mission or role; 

4. efficient use of Coast Guard resources. 

There were two initial strategic drivers for the BACS project. One 
was the goal to standardize the equipment suite used by VTS San 
Francisco with the equipment suites being installed at VTS New York and 
VTS Puget Sound. The other strategic driver originated in Congress. The 


goal was to free up a portion of the government controlled frequency 


spectrum for civilian use. 


23 


There are other existing strategic drivers, however, that must be 
researched before all the functional requirements can be addressed. 
Some of these strategic drivers are being brought on by the Coast Guard 


streamlining effort. In particular, these drivers include the following: 


1. the merging Eleventh District with Pacific Area; 


2. the transfer of support functions from district offices to the 
MLC’s; 


3. the inception of Activity Commands effecting the command and 
control structure of groups, Marine Safety Offices (MSO’s), air 
stations, and VTS’s. [Ref. 12] 


Again, it is imperative we know where we are going, if we are to perform 


effectively and efficiently. 


2. Functional View 

Using the functional view, we need to answer the question, “What 
HQ or unit functional requirements cannot be met without the project?” 
These requirements are extrapolated from the strategic drivers; however, 
they will usually come in the form of requests from units, or programs, to 
change or upgrade functional capabilities. It is important to justify the 
changes in functional requirements to their strategic drivers. Project 
proposals which support G-T goals generally get high priority for 
approval and resources [Ref. 13, p. 21]. This statement could also 
include Area and Program managers goals, depending on the source, 
control and availability of resources. 

Some of the BACS functional requirements that cannot be met by 


the existing system include, but are not limited to, the following: 


1. the ability to transfer digital data from remote sites to VTC San 
Francisco; 


2. the implementation of new digitally-controlled equipment, 
including VHF radios, direction finders, and radar processors; 
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3. rerouting of signals, in the event of a link failure, within the 
telecommunications system. 


3. Physical View 

Using the physical view, we need to answer the question, “Is there 
anything from the physical view that is causing the project?” These 
could include equipment issues (e.g., lack of replacement parts, 
reliability, etc.) or maintenance issues (e.g., high maintenance costs, lack 
of trained maintenance personnel, etc.). In the BACS case, the 
equipment cannot meet the new functional requirements (i.e., operating 
outside the 2 GHz frequency spectrum). The equipment also has high 
maintenance costs and lack of manufacturer support for replacement 


parts. 


E. THE TENTATIVE OPERATIONAL REQUIREMENT (TOR) 

The TOR is the initial phase in the formal requirements validation 
process and is usually submitted by the support/operating program 
manager when there is a perceived need for a new operational capability. 
The contents for a TOR are listed in Figure 4. The TOR is analyzed by G- 
T (or MLCt) branch personnel to verify the requirement, determine if a 
Development Options Paper (DOP) is required, and provide alternative 
solutions. The project officer may have to assist the program manager 
(or requesting command) in writing the TOR. This is an advantage 
because it gives the AWG an early opportunity to help identify the real 
needs. If the formal process is not being used --which is likely--then the 
project officer should develop a “straw” TOR using the same format. 
When the straw TOR is submitted to the branch chief, it will demonstrate 
that the project officer has done the homework necessary to identify the 


true issues. [Ref. 13, p. 23] 
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The TOR summarizes all the end products of phases I and I. 
Using the executive guidance provided, the design team will have 
explained the purpose of the system. By developing the high-level 
functional requirements, the AWG can envision the desired end-state 
system and outline an initial plan for achieving this vision. The problem 
has been bound by using the organizational, functional, and physical 


views. 
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Vi. 


VUl. 


XII. 


FORMAT FOR TENTATIVE OPERATIONAL REQUIREMENT (TOR 


(3-page limit, excluding cover sheet) 





Cover Sheet. Serves in lieu of forwarding letter. 
Subject/Title. Provide a short one line subject/ title. 


General Description of Operational Requirement. Describe the type of 
system needed and its general concept of operations. 





Threat. The threat section should either address the threat the system is 
being designed to counter, the threat environment in which the system 
must operate, or the threat to the environment that must be resolved. 


Deficiencies /Shortcoming of Existing Systems. At a minimum classify the 


deficiency as one of the following: 


A. Operational Deficiency - inhibits the performance of a mission or the 
execution of operational plans. 


B. Characteristic Deficiency - inhibits the performance of mission in 
accordance with doctrinally prescribed characteristics (connectivity, 
security, speed, reliability, interoperability...etc.) 


Cc. Conceptual Deficiency - deficiency, when corrected can materially 
improve operations by providing new capabilities; solutions will 
require significant development. 


Range of Capabilities Desired. Outline, in general terms, the key 
capabilities desired. Include capabilities required versus adverse ocean 
environment sensitivities. Allow broadest possible range of acceptable 
performance levels from modest improvement of existing systems to major 
advances. 


General Affordability limits. Provide an estimate (round numbers) of what 
the resource sponsor is willing to pay (in constant dollars, using current 
year dollars for: a) RDT&E; b) average unit costs; and c) life-cycle cost 
(RDT&E, procurement, installation, and five years of operation, all 
appropriations). This affordability limit serves as a constraint, rather than 
a fixed limit, for preparing the DOP. 


Facilities/Platform/Quantities. Identify facilities/ships/ aircraft, etc. which 
will employ the system (if applicable), and estimate number to be procured. 


Integrated Logistics Support (ILS). Describe any required or limiting logistic 
planning considerations, including manpower/personnel/training. Provide 
essential direction regarding the nature of the program required including 
compliance with or exceptions to key policies and/or procedures. 





Background/Related Efforts. Discuss interfacing systems, companion 
developments, etc.. Identification of foreign systems that can reasonably 
satisfy the range of capabilities specified shall be specifically requested in 
the TOR. 





Program Manager. Clearly identify all programm managers, who will be the 
end user of the system. Also identify any other program managers who will 
be affected by the acquisition. (i.e., the program managers of all floating 
platforms or shore stations). 


Acquisition Strategy. Summarize overall plan for contracting and 
procurement, including contract type and incentives. 


Figure 4: Tentative Operational Requirement (TOR) 
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F. CONCLUSION 

Phases I and II are the foundation on which any project is founded. 
If the project officer is not aware of the driving issues behind the 
decisions made during these phases, the project can quickly get off track. 
The project officer should not only make a great effort to understand the 
driving issues, but should be willing, and allowed, to question the issues 
and decisions made during these phases. The Coast Guard’s Command, 
Control, and Communications (“T”) leadership must form and 


disseminate a well-defined set of strategic objectives for the community. 
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IV. BASELINE CHARACTERIZATION 


A. INTRODUCTION 

The baseline characterization is the third process, or phase, in the 
Structured Approach Model. The purpose of a baseline characterization 
is to provide the design team a better understanding of the existing 
system. The baseline characterization must cover both the 
telecommunications network and the users systems. 

A baseline characterization of the existing systems is a critical phase 
in the process of targeting and developing either a follow-on or new 
telecommunications network. Without examining the current systems, it 
is difficult to determine the degree to which the telecommunications 
network must be upgraded or replaced. Determining the existing systems 
objectives, processes, and performance permits the design team to target 
an architecture that best fits the functions and objectives of the enterprise. 
The enterprise integrates processes and procedures, both manual and 
automated, for all Coast Guard mission areas and their associated 
functions. In our analysis, the “enterprise” is comprised of U.S. Coast 
Guard units in the San Francisco Bay Area that use the BACS. 


To better understand the system, the design team will ‘use the 
baseline characterization to generate a high-level description of the 
physical aspects of the user systems and existing telecommunications 
network. The design team will take the mission goals and high-level 


functional requirements gathered when we “defined the problem,” and 
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break them down into more detailed requirements. These requirements, 
in turn, will be broken into actual work processes and tasks which must 
be completed to meet the requirements. Again, we will use the functional, 


the physical, and the organizational perspectives to accomplish this. 


B. ORGANIZATIONAL VIEW 

The organizational viewpoint is concerned with the actual working 
processes used by the enterprise to meet its functional goals. These 
include working processes which are performed by personnel or by 
equipment. For example, a functional requirement may state, “Group 
duty watchstanders shall transmit marine safety notices every four hours 
simultaneously over the group area of responsibility (AOR).” This 
requirement would include working processes performed by the 
watchstander (prepare Notice to Mariners, manually press switch, and 
speak) and those performed automatically by the equipment and 
software to enable the signal to transmit over numerous VHF-FM radios 
concurrently. 

When completing a baseline characterization on a complete 
information system, all work processes performed by the enterprise 
should be considered. As engineers, we must understand the work 
processes if we are to design the new information system to be both 
effective and efficient. Some work processes are effective, but are not 
efficient. Prior to a telecommunications replacement project is the 
perfect time for the Coast Guard enterprise to consider re-engineering 
inefficient work processes. Normally, however, the telecommunications 
network design team will have very limited resources. Therefore, the 


scope of this paper is limited to those work processes directly related to 
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the telecommunications network and the system applications that 


interface through the network. 


1. Determine the Organizational Structure 

The definition of organizational structure used here is, “The 
structure which controls the flow of the work processes.” This entails 
two aspects the design team must keep in mind: 1) the sequential 
procedures which must be performed to complete the process, and 2) the 
physical location of resources used to perform the processes. For a 
simple illustration of how important these two aspects are to 
understanding the system, we will take another look at the watchstander 
example. The sequential procedures include switching the console 
controls to an “all broadcast” position, which in turn initiates software 
that sends a control signal simultaneously over the telecommunications 
network to all VHF-FM remote sites. This signal switches the radios to 
the transmit position. However, the design team must be aware of the 
locations of the VHF-FM radios if they are going to design a 
telecommunications network to pass these signals. This example shows 


where the organizational and physical views converge. 


C. Functional View 

The functional view addresses the fundamental issue of what the 
system enables the enterprise to accomplish. This has two aspects. The 
design team must consider 1) each unit’s functionality and 2) the role the 
existing telecommunications system plays in achieving the unit’s 
elemental missions, The functional viewpoint's relationships to the 
physical and organizational viewpoints must also be considered. 

On a superficial level, the BACS provides simple connectivity 


among the entities comprising the Coast Guard in the Bay Area. 
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However, a more careful analysis reveals that the BACS provides the 
enterprise with a wide variety of functionality. These functions can be 
categorized as both mission area functions and support functions. 

Many of the mission area functions derive directly from the 
legislated responsibilities of the Coast Guard. These mission area 
applications are those which directly interact with the Coast Guard's 
external customers. These interactions are manifested in artifacts such 
as marine safety information, operational unit employment metrics, 
Broadcast Notices to Mariners, distress messages, and Urgent Marine 
Information Broadcasts. 

However, in this context, mission area functions additionally 
include those applications required to implement all specific end-user 
requirements, e.g., personnel management information for internal 
Coast Guard use. 

BACS' support functions include those common applications which 
are standardized across the various mission areas. These underlying 
services are available to several mission area functions as needed. Ina 
distributed architecture, these applications would provide such services 
as electronic mail, text editing, and spreadsheet functionality. They 
would serve as building blocks which could be called by other 
applications, remotely, to contribute to their own functionality. 

In the BACS case, the services and functionality provided by each 
layer of the ISO/OSI 7 layer model of telecommunications provides a 
similar underlying suite of support applications. For example, the 
transport layer provides error and flow control services across the 
network to the session layer above it. 

In large measure, the functions the BACS performs in support of 
the Coast Guard are derived from the missions assigned to the Coast 


Guard itself by the U.S. Congress. Systems designed to meet functional 
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objectives can have other, dramatic effects. The virtual organizational 
reengineering that a networking infrastructure such as BACS can 


implement could help initiate and expand a horizontal integration. 


1. Functional Requirements of the Enterprise 


a. Determine the Users’ Functional Requirements 

Each unit has their own mission requirements, and therefore 
their own functional requirements. These requirements are the basis for 
the system specification. 

Gathering and documenting functional requirements is a 
collaborative effort. The project officer must work with the users, and 
other CG entities, to fully document these requirements. These include 
mission sponsors (HQ program offices), support facilities, users within 
each unit division and chain of command. This collaboration will ensure 
all the functional requirements are documented and ensure functional 
requirements have not been misconstrued between the different entities 
involved. Everyone must be working from the same sheet of music, so to 


speak. 


b. Rank User Requirements 

The level to which every mission is fulfilled must be limited. 
Limiting the mission also limits the functionality required. The limiting 
factor(s) can be cost, technology, time, law, or any number of other 
factors. Normally, the functional requirements necessary to complete the 
mission are not spelled out in black and white. Every entity involved with 
the mission (i.e., mission sponsor, district, unit commander) may have a 
differing view on what level of functionality is necessary. 

For instance, the mission for the Vessel Traffic Service (VTS) 


is to foster safe travel for vessels of a certain size or type through San 
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Franciscan waters, as designated by Congress. One level of functionality 
would be to prevent collisions between participating vessels. Other levels 
of functional could include preventing collisions between participating 
vessels and pleasure boats, or between participating vessels and floating 
logs. These three different levels of functionality require different levels 
of technical capability. The VTS would like to prevent collisions between 
ALL participating vessels and pleasure boats and floating logs. This is 
great for customer satisfaction, as well as job satisfaction. However, the 
mission sponsor, in this case (G-N), must be willing to foot the bill for the 
additional technical capability necessary to provide the desired level of 
functionality. 

What must be considered is the incremental differences 
between meeting the different levels of functionality and whether the unit 
(or sponsor) is willing to pay those incremental costs. The three different 


mission requirements mentioned above could be categorized as follows: 


e CATEGORY 1: “must have” - the functionality required to prevent 
collisions between participating vessels. This is the functionality 


which all agree is necessary for mission success. 


e CATEGORY 2: “should have” - the functionality required to 
prevent collisions between participating vessels and pleasure 
boats. This is the functionality which many feel is necessary for 


political or PR reasons. 


e CATEGORY 3: “nice to have” - the functionality required to 
prevent collisions between participating vessels and floating logs. 
This is the functionality which would make the mission much 


easier or satisfying, or add to the public’s view of the Coast Guard. 
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Once a unit’s functional requirements have been noted, each 
functional requirement should be placed into one of the three categories. 
This will help us during the upcoming phases of the structured approach 


model. 


2. Matching Functionality to the Information Systems 

At another level of abstraction, however, we can focus on the 
specific functions the BACS system provides in achieving the unit’s 
elemental missions. This functionality is provided through ten coherent 
systems. Each is used to gather or disseminate information; therefore, 
we shall refer to them as information systems. These ten independent 
information systems can be drawn upon by the enterprise in many 
varying combinations of functionality. 

The information systems that operate over BACS to provide 
enterprise functionality are outlined in the following ten subsections. 
Table 1, starting on page 41, contains an inventory of the information 


systems available at each existing site. 


a. Coast Guard Data Network (CGDN) 
(1) Description 


CGDN is the Coast Guard's INTERNET, with access at 
all stations within the BACS. Each location has a computer terminal 
which is linked via microwave to either Coast Guard Island or Group San 
Francisco. These two sites are linked directly into the CONUS-wide 
WAN, enabling direct contact with all other CG entities. A functional 
block diagram for the CGDN can be found in Appendix B on page 150. 


(2) Functions 


1. Electronic mail; 


2. Record message traffic (naval messages); 
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. Marine Safety Information System updates; 
. Search and Rescue Management Information System updates; 


Law Enforcement Information System updates; 


na kw 


Large Unit Financial System updates. 


b. VHF-FM (Voice) for Vessel Traffic System (VTS) & 
National Distress System (NDS) 


(1) VTS VHF Description 


VTS is a VHF-FM radio system linked on land by 
microwave, with transmit/receive sites located along the coast. A 
functional block diagram for the VTS can be found in Appendix B on 
page 151. 


(2) VTS VHF Functions 


VTS is a system used by Masters, Pilots, and 
Commanding Officers piloting commercial and government vessels in the 
waters subject to the jurisdiction of the Vessel Traffic Scheme (areas in 


and around San Francisco Bay). 
(3) | NDS VHF Description 


NDS is a system similar to the VTS but broader in 
scope, with coverage from areas north of San Francisco (around Bodega 
Bay) to south of Monterey. While Figure 5 contains a simple illustration 
of the NDS functionality. 


(4) NDS VHF Function 


The system carries out three completely separate 


functions: 


1. Command and control of Coast Guard cutters, boats, and 
aircraft in the coastal region; 
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2. Voice radio interaction with the public; 


3. Receipt of reports from mariners in distress. 





GROUP 
MONTEREY xX 


S N 
=~ 
CGAIRSTA 
SANFRANCISCO 


ts “%, 
C&C, 


GROUP A; 
SAN FRANCISCO 


ms sO 
~ 


SANFRANCISCO 
CGISLAND 





Figure 5: VHF NDS Functionality Illustration 


Cc. Air Control UHF Voice/Data 
(1) Description 


This UHF/Data System connects Air Station San 
Francisco with Coast Guard Island, and utilizes Mt. Tam asa 
transmit/receive high site for extended range coverage around the San 
Francisco Bay Area. A functional block diagram for this system can be 


found in Appendix B on page 152. 
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(2) Function 


The UHF/Data System enables Air Station San 
Francisco to exercise longer range command and control and allows 


Coast Guard Island to monitor the channels. 


d. High Speed Teletype/Data Network (/HDN) and PACINT 
(1) Description 


HSTN/HDN is the primary means of teletype (hard 
copy) message communications for Bay Area Coast Guard units. PACINT 
is an intelligence support link between COMMSTA San Francisco and 
PACAREA at Coast Guard Island. A functional block diagram for this 
system can be found in Appendix B on page 154. 


(2) Function 


HSTN/HDN supports the PACINT system and all other 
BACS teletype users for data dissemination for law enforcement and 


intelligence purposes. 
e. CGI Phone (Telephone PBX System) 
(1) Description 


This system is composed of microwave links between 
various sites, telephone handsets, and a BACS to PBX link located at 
Coast Guard Island. A functional block diagram for this system can be 


found in Appendix B on page 155. 
(2) Function 


Provides telephone service throughout the BACS area, 
and provides a connection to Public Switched Telephone Network (PSTN) 


and Federal Telephone System (FTS). The system is used as an in-house 
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backup for civilian PSTN and FTS and as a maintenance phone for 


technicians working at BACS microwave sites. 


f. Miscellaneous Systems (HF Radio, Video, Radar, 
CAMSPAC Link, Alarms) 


(1) Description 


All of these systems are composed of similar two-way 
links from a home site to a remote site, with various functions as 
described below. A functional block diagram for these systems can be 


found in Appendix B on page 156. 
(2) Functions 


The HF radio system provides high frequency voice 
communications from Group San Francisco to ships at sea, transmitted 
and received over radio equipment located at Point Bonita. Control sig- 
nals which operate the equipment are also sent via microwave. 

CCTV video signals are transmitted over T-1 lines from 
four remote sites to the VTS center. The video is used to observe vessel 
traffic as part of the VTS. Camera control signals are sent via T-1 from 
the center to the individual cameras to select the desired field of view. 

Radar signals are transmitted over T-1 lines from one 
remote site at Point Bonita to the VTS center. The radar data is used to 
observe vessel traffic as part of the VTS. Radar control signals are sent 
via microwave from the center to the radar antennae. 

CAMSPAC Link provides a large number of audio, 
data, and control signals, via microwave, between the transmitting and 
receiving sites at the Communications Area Master Station. 

Alarm signals are transmitted from remote sites, via 
microwave, to a monitoring station. This system is used in maintaining 


the status of aids to navigation as part of the Aids Control and 
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Monitoring System (AMSC). Alarm signals for security and equipment 
located at the remote sites are also transmitted back to monitoring 


equipment on CG Island. 
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Table 1: BACS Information System Inventory 
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VHF-FM NDS — VHF-FM National Distress CG Island’ _ Audio VHF-FM Radio 
System Group San Francisco 
Group Monterey Control Operator.Console 
Station Mare Island : 
Station Rio Vista. 
Station Bodega Bay 
Mount Tamalpais 
Mount. Diablo 
Point Bonita 
Mount Umunhum 
Mount Jenner: 
Pigeon Point (landline) 
Carquenes Heights 
TV Hill 











VTS VHF-FM Vessel Traffic System VHF-FM VTS San Francisco Audio VHF-FM Radio _ 
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D. PHYSICAL VIEW 

The physical view will outline the physical configuration, 
coordination, and resources required by the existing system to operate 
efficiently and effectively. The physical view will be broken into three 
sections: 1) physical architecture, 2) physical sites, and 3) maintenance. 
The relationships of the physical viewpoint to the organizational and 


functional viewpoints are also of concern. 
1. Physical Architecture 


a. General Description 
The Bay Area Communications System (BACS) is an 
analog microwave system which operates in the two gigahertz (GHz) 
frequency range. BACS links at least eleven Coast Guard units to remote 
sites using 18 microwave radio links. Each unit is also linked to external 
networks (e.g., PSTN) through the telephone PBX system located at the 


communications system’s hub on Coast Guard Island. 


b. Existing System Configuration 

Since the entire analog microwave system will be replaced, 
an in-depth study of the existing system’s physical configuration and 
operating characteristics is unnecessary. However, a list of major 
components with their descriptions and locations will be necessary 
during the removal phase. 

Of major concern are the existing circuit configurations. A 
detailed study of each existing circuit must be completed. Information 
gathered on each circuit should include at least the following: 

1. Bandwidth required 


2. Signal formats/interoperability requirements 
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3. Locations of circuit connections 
4. Sensitivity to data delays 


5. Sensitivity to disruptions in service 


This is to ensure the requirements of all existing circuits are considered 


when choosing and designing the network replacement. 


c. Hardware Components 

Most microwave links have a single antenna at each end. 
Each link end also has a receiver, transmitter, and "hot standby" 
transmitter. This "hot standby" transmitter automatically assumes the 
transmission responsibilities when the main transmitter fails. Two of the 
BACS microwave links cover long distances over water. The water 
reflects the signal, causing a second signal to arrive at the receiving 
antenna shortly after the intended signal. These signal reflections cause 
multipath reception problems. Additional antennas and a technique 
known as space diversity are used at each end of these links to overcome 
the multipath reception problems. This approach enables the system to 


function effectively despite the long over-water paths required. 


2. Evaluating the Existing System Baseline 

An evaluation of the existing network must be completed. A “list of 
network deficiencies” should be compiled and include items such as 
links with high-fade margin rates, and required services not provided by 
the existing system. A “list of opportunities” should be collected and 
include items such as excess circuits and circuits that can be combined 


or deleted entirely. 


a. Measures of Performance 
Measures of performance (MOP) can be used to indicate 


whether or not a network meets the functional or technical requirements 
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it was intended to satisfy. The Coast Guard has not been using any MOP 
to track the microwave network’s overall performance. No records of 
network failure, calibration, or component replacement have been 
generated. 

However, there are four communications-oriented measures 
of performance used by the Coast Guard to ensure the communications 
links between sites remain within nominal specifications: 

1. Fade Margin - Measures signal attenuation across a microwave 
link 
2. Receiver Signal Level - Measures carrier signal power level 


3. Baseband Level - Measures the incoming Baseband signal 
strength 


4. Idle Channel Noise Level - Measures the amount of noise 
created by the microwave system itself. 


Since any alternative supporting system would likely be 
based on a different technology, additional development of MOP for the 


existing network would not be beneficial. 
3. Physical Sites 


a. Types of Sites 

There are four fundamentally different types of physical 
locations (sites): "Mega-station" (Group San Francisco and Coast Guard 
Island), "station,” "relay high site,” and "navaid/end site.” Their 


descriptions are as follows: 


i. The "mega-station" category includes both Group San 
Francisco and Coast Guard Island, the two primary 
communications hubs that support the command and control 
structure for this region of California. The two sites contain all 
or most of the communications systems previously described 
above in Section B, Functional Architecture. A drawing 
showing a consolidated version of the two sites can be found in 
Appendix B on page 156. 
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A "station" includes sites such as Group Monterey, Bodega 
Bay, and Air Station San Francisco. These sites are primarily at 
the operational level, and control specific missions within their 
respective areas of responsibility. "Station" sites either control 
or receive information from "navaid/end sites" directly or via 
"relay high sites.” A drawing showing a generic version of a 
"station" can be found in Appendix B on page 157. 


"Relay high sites" are located on topographically high 
locations throughout the BACS area, and provide the line-of- 
sight necessary for the microwave communication links, and 
good transmit/receive locations for the UHF/VHF radios. These 
sites connect from two to six microwave links together. A 
drawing showing a generic version of a "relay high site" can be 
found in Appendix B on page 158. 


"Navaid/end sites" are primarily remote sensor (radar, 
television monitor, radio antenna) or navaid sites (light house). 
Control signals for these remote sites are received via 
microwave or T-1 lines, and the sensed data is returned to the 
controlling station via similar means. A drawing showing a 
generic version of a "navaid/end site" can be found in Appendix 
B on page 159. 
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b. Site Configuration 


Each site must be visited and an evaluation of its physical 


limitations such as space, power, “heating, ventilation, & air 


conditioning” (HVAC), remoteness, tower limits, etc., must be completed. 


A table, such as that in Table 2, can be developed to assist the project 


Table 2: Site Configuration Table 


Floor Space 
Avail (Ft) 
Blkhd Space 
Avail (H x W) 
A/C 
Circuitbreakers 
Avail 

Rack Space 
Avail (H X W) 
UPS Power 
Avail 


Tower Weight 


Limit 





6x5+2x8 


3 (20a) + 1 
(50a) 


Approx. 15a 





6x4+3x8 


3 (20a) + 1 
(50a) 


Approx. 20a 





8x4+2x2 








6 (20a) + 2 
(50a) 








officer in documenting the sites physical limitations. This table will be 


essential when selecting alternative technologies and equipment for each 


site. 


c. Maintenance 


Network maintenance is performed to prevent or limit loss of 


communications, and repair the network after failure. The maintenance 
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resources required for the new network will normally differ from those of 
the existing network. However, a baseline of resources used to maintain 
the existing network is essential for planning. The project officer can use 


this baseline to: 


1. compute the estimated costs associated with maintaining the 
existing network; 


2. estimate the resources required for the replacement network; 
3. estimate maintenance costs for the replacement network; 


4. plan changes to the existing maintenance structure (including 
contracts, billets, ordering procedures, etc.). 


Since maintenance resources used for the 
telecommunications network may also be used for other purposes, the 
maintenance resources must be broken down to a level low enough to 
make these overlapping uses apparent. 

CG telecommunications networks can use both CG and 
contract resources. Quarterly and annual preventive maintenance is 
performed by Coast Guard Telephone Technicians assigned to the 
Telephone Technician Shop on Coast Guard Island. Preventive 
maintenance for BACS is both costly and very time consuming. 
Technicians are required to be at both ends of any analog microwave link 
when the network is being adjusted. This adds greatly to the amount of 
travel time required. Unlike a digital network, an analog network does 
not remove noise at each relay site by regenerating the original signal. 
Therefore, the network must frequently be fine-tuned to reduce noise 
interference. 

Emergency maintenance is performed by the Coast Guard 
technicians when a link fails. Although no maintenance records have 


been kept, technicians indicate that approximately 1-2 failures occurs 
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each year. The link is normally restored within 3-4 hours, but, a link 
has been inoperative for as long as three days. 

The project officer must also consider maintenance to the 
building structures and surrounding grounds. At times, this 


maintenance is more difficult to arrange than network maintenance. 


d. Overall Assessment 

Without regard to the costs of operating and maintaining the 
network, BACS has satisfied the original requirements of a privately- 
owned communications network. When evaluating the cost side of a 
cost/effectiveness assessment, however, the continued use of BACS is 
questionable. 

The network incurs explicit costs in a number of areas, 
including: 

1. Salaried maintenance technicians continuously on call; 

Electric power consumption; 


Recurring hardware replacement; 


Pe SS 


Recurring preventive maintenance. 


Implicit costs of the network are more problematic. The 
most significant of these is caused by BACS being firmly entrenched in 
an obsolete technology: the analog microwave network provides no 
migration path to high speed digital technology. The opportunity costs 
associated with the limitations of this infrastructure are severe. 

The most immediate shortcoming exists in the lack of 
significant broadband digital connectivity between 1) the Commander, 
Pacific Area's headquarters in Alameda, and CAMSPAC; and 2) the VTC 
and remote radar sites. This shortcoming immediately prohibits the 


implementation of the Coast Guard's goal to eliminate all dedicated 
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communications personnel at the Alameda Command Center and 
headquarters. 

While a concrete capacity figure is not forthcoming from the 
users, the existing technology clearly does not support the present vision 
of the organization. 

Reliance on non-secure command and control links via the 
VHF-FM system prevents the organization from achieving it is command 
and control requirements under it is national defense tasking. 
Limitations of the existing network again prevent the organization from 
migrating to communication and encryption systems compatible with the 


DOD. 


E. CONCLUSION 

The baseline characterization is essential to understanding where 
we are going and how we will get there. A well documented baseline 
characterization can prevent the design team from overlooking many of 
the smaller details that turn into major problems as the project moves 
forward. By using the Structured Approach Model, a project officer will 
ensure all aspects of the baseline characterization have been considered. 

Opportunities for reengineering are clear. Feasible target 
architectures should be explored. A target architecture should be chosen 
which best matches the anticipated future requirements, expected 
technology maturation, and realistic funding levels achievable. A 
cost/effectiveness analysis must be conducted to support the 
procurement decision. A privately owned microwave network is only one 


of several possible alternatives to meet the future requirements presently 


served by BACS. 
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V. TARGET ARCHITECTURE 


A. INTRODUCTION 

“Determine Target Architecture” is the fourth process of the 
Structured Approach Model. Recall that the design team must determine 
target architecture for each of the users systems before a network target 
architecture can be considered. The purpose of the Target Architecture 
process is to outline the technical capabilities the final network 
configuration must possess to meet the user requirements. 

The new architecture need not be developed based on cost-effective 
or “business case-based” criteria. The real world constraints of 
cost/effectiveness analysis and cost justification will be introduced in the 
“Select Migration Path” phase of the Structured Approach Process. 

At this phase in the process, it is desirable to define a target 
architecture that can be used to achieve the vision of the organization 
from all three views. Ultimately, constraints will come to bear on the 
funding of each project that is needed to achieve the target; but, for now, 
it is sufficient to flesh out the target to identify the full spectrum of what 
is needed to achieve the vision of the organization [Ref. , p. 4-3]. 

Sometimes an organization cannot implement the target 
architecture without either disrupting the quality of service provided to 
the enterprise or expending an excessive amount of resources to get 
there. Therefore, it is important that the design team take the time to 
outline a set of alternative architectures that may become an interim 
target until the ultimate target can be legitimately reached. 

There are four conceptual levels of architecture that should be 


discussed; these are shown in Figure 6. The “baseline” is the 
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architecture that already exists; the “migration path” could contain a 
number of configurations to be implemented over time to reach the final 
target (the first of these is known as the “base system”); the “modified 
target architecture” is the future architecture we may have to settle for 
due to system or cost constraints; and the “ultimate target architecture” 
is where we finally want to get. 

This section describes the overall process by which the 
architecture framework is extended by the design team. The issues for 


the design team to be concerned with during this process include: 


1. An extension of the vision as described in the “Organize and 
Plan” process; 


2. A description of the future enterprise and a desired future 
architecture required to meet future functional requirements; 


3. An identification of what can be extended from the current 
environment into the target environment. 


But what can the design team do if no vision exists for a future 


architecture? This can be either a blessing or a curse, depending upon 


| ultimate | 
target 


| architecture | 


a] 

modified | 
target 

architecture | 
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architecture 
(path) 


———— 


basline 
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Figure 6: Four Levels of System Architecture 
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how much effort the design team (and the enterprise) is willing to put 
forth on the project. It is much like an artist being given a blank canvas 
and told to paint the future. If the artist expends some effort in research, 
he can get very close to the near future. Like the artist, if the design 
team does its research, they can target an architecture that will normally 
meet the enterprise’s future needs But, without the research, it isjusta 
stab in the dark. 

Now, we will take a look at some procedures the design team can 
use to design the target architecture. Here again, the three views have 
been used to ensure all perspectives are considered. Figure 7 depicts an 
overall framework the design team can use while developing the target 
architecture. As we saw in the earlier phases, each view of the target 
architecture has some overlap with aspects of the other views (see Figure 
8, Figure 9, and Figure 11, below). This overlap supports the argument 
that we are developing a single, integrated architecture [Ref. 8, p. 4-4]. 
The design team can frequently refer to this meta-model in order to 


remain focused on the key aspects of the task at hand. 
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An Integrated Model with Component Relationships 
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Figure 7: Integrated Model with Component Relationships (TAFIM Vol. 4) 
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B. ORGANIZATIONAL VIEW 


1. Changes to the Existing Organizational Structure 

The organizational structure can be looked at in two different 
context. One is from the task prospective. This includes the enterprise 
tasking and the information flow required to perform the functional 
requirements. The other context is from the enterprise unit, or 
command, structure. Figure 8 highlights those areas that the design 
team should keep in mind while concentrating on the organizational 


view. 





Figure 8: Integrated Model Highlighting Organizational View 


When evaluating the users systems, the tasking should be studied 


in great detail and changes recommended where appropriate. This 
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should be done with complete disregard for the unit structure. [Ref. 8] 
For example, suppose we are designing a new centralized information 
system for tracking cargo and shipping data for U.S. ports. The data is 
normally supplied to Coast Guard Headquarters’ (CGHQ) from the VTS in 
the form of quarterly reports; they, in turn, have gathered the 
information from the port authorities. Looking at it from the unit 
structure context, we might electronically collect the information from 
the VTS. Looking at it from the tasking context, we see that it would be 
more efficient to electronically collect the information directly from the 
port authorities. 

Although the design team may have very little input into task 
reassignment, it should still take a broad look at the tasking necessary to 
perform existing and anticipated future functional requirements and 
make recommendations for change where necessary. In this manner, the 
command structure will have the option to reengineer the tasking before 


the new system is put in place. 


2. Determine Other Potential Network Users 

Depending on the location and the type of telecommunications 
network implemented, other government entities may have 
telecommunication requirements that can be accommodated on a CG 
owned network. Although, at this point the type of network to be 
installed will not be known, the design team should keep this in mind 
when visiting the enterprise sites. They should inquire into any other 
government interests that are located near the sites. Other government 
entities would be responsible for providing their signals to demarcation 
points located at the necessary sites. They can also be required to share 


in the costs of the network. Since participation by outside agencies 


56 


could affect the target architecture to be chosen, these agencies should 


be contacted as early as possible. 


C. FUNCTIONAL VIEW 

To reiterate, functional requirements are those functions which 
must be completed by the enterprise for their mission(s) to be a success. 
We have already researched the existing functional requirements during 
the basic characterization phase. Now, the design team must determine 
what new functional requirements may be added in the future. While the 
Coast Guard’s missions and functional requirements for seven to ten 
years from now are not documented, there are signs which point to the 
direction in that we are heading. Many of these signs are now being 
posted by our leaders in the Congress, the Coast Guard, and the rest of 
government. 

Each of the program offices in CGHQ have assigned planning 
staffs. They possibly have already gathered information from government 
sources, industry, national and international committees and combined 
it with their own plans for the future. Their plans control the future of 
the network users. Therefore, the knowledge contained within their 
plans must be captured and incorporated by the design team. 

It is up to the project officer and his command to determine what 
method is used to gather this information. One method would be to hold 
face-to-face meetings with the subject experts. This is the easiest way for 
many people to brainstorm and participate in true dialogue. However, I 
would recommend that before any meetings are held, the project officer’s 
command send a formal letter to spell out the purpose, the plan, and 
request an individual be assigned to work with the design team. This 
will allow each office to properly assign the task and begin the necessary 


research. This may seem like an inordinate amount of work, but proper 
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planning pays off. Once this information is obtained, meetings can be 
held to assess the impact on the enterprise’s organization and mission 
requirements, and negotiate the level of functional implementation. 

By assessing the likelihood of major changes to the Coast Guard, 
and therefore the functions and missions, we can better analyze the risks 
of different target architectures. For instance, one alternative may meet 
today’s requirements, but not be adaptable to future technology. 
Another alternative may provide more versatility for the future, but ata 
higher cost. This assessment of functional and mission change should 
lead to a number of different scenarios, each with its own set of missions 
and functional requirements. These scenarios should be deeply 
deliberated on by the design team to ensure the target architecture 
chosen will have the highest probability of meeting the enterprises future 
requirements. Figure 9 highlights those areas that the design team 


should concentrate on while researching the functional view. 
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Figure 9: Integrated Model Highlighting Functional View 


The functional requirements of the existing missions must be met 
by the base system (1st migration configuration). For each scenario, the 
future functional requirements of each unit should be compared to the 
existing functional requirements. If they are the same, or have 
diminished, they may be disregarded. If different, they should be 
properly labeled and added to the list of functional requirements. 

We now have a completed list of functional requirements which 
include those from the baseline characterization and the additional 
functional requirements considered for the future. It is now time for 
another round of dialogue and negotiation between the entities having a 
stake in the project. This group must categorize the requirements into 


one of the three categories, “Must Have,” “Should Have,” or “Nice to 


59 





Have.” Here again, dialogue and negotiation are the keys to developing 
an acceptable plan. This category information will be used to develop 
relative values for the functional requirements during the following 
phases. 

A date indicating the year that a functional requirement will be 
required should be attached to each requirement. The configuration 
shown in Figure 10 will be used here to represent each functional 
requirement. This notation will be very useful during the follow-on 


phases. 


Fn,, 


: the function 
: the assigned function number 
: the category the function is assigned to (i.e., 1, 2, 3) 


: the year the function is required 





Figure 10: Symbol Configuration Representing Functional Requirements 


Determining the final categories for each requirement, and the 
date each is required, will take a considerable amount of dialogue and 
negotiation. The project officer must facilitate this dialogue between the 
program managers, the commands, and the different levels of users. His 
role is critical if the final systems are to be the most efficient and effective 
available. The final categories and dates for each functional requirement 
may depend upon the results of the cost/effectiveness analysis 
performed in the next phase. Another round of negotiations may be 


necessary at that time. But for now we will assume they will not change. 
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D. PHYSICAL VIEW 


The areas the design team should be concerned with while 





Figure 11: Integrated Model Highlighting the Physical View 


concentrating on the physical view are highlighted in Figure 11. 

While developing the target architecture’s physical view, what is 
important is the underlying architecture, not particular equipment suites 
or software bundles. To define the target architecture, TAFIM uses the 


terms Generic Application Environments (GAE), Generic Technology 
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Environments (GTE), and Generic Technology Platforms (GTP). The six 
GTP’s and examples of GAE’s and GTE’s can be found in Table 3.2 

In the absence of promulgated standards, the design team must 
choose the standards to be incorporated. To implement a standards- 
based infrastructure, it is important to consider the scope and depth of 
the standards to be adopted. Fundamentally, all cases of standards 


adoption require answering three questions: 


1. What standards should we adopt? 
2. Where in our architecture should we adopt them? 


3. When should we adopt them? 


Standards should be selected for the users systems, as well as the 
telecommunications network. TAFIM, Volume 2, should be used in this 
phase. It suggests a standards-based model with sections for user 
interface, database, applications, operating system, communications, 
languages, management, and other services. The design team must be 
prepared to define the details that underpin each of the above sections of 
the model required for project implementation. TAFIM, Volume 4, 
Appendix C, can also be a good reference point for teams attempting to 


define the details of the standards model. [Ref. 8, p. 4-28] 





1 TAFIM, Vol. 4, Appendix D contains complete definitions for these terms. 


2 An abbreviated definition for each of the GAE’s, GTE’s, and GTP’s listed can be found in the 
Glossary. 
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Table 3: Examples of GAE, GTE, & the Six GTP 






Batch processing 





Transaction processing 





Inquiry processing 





Decision support 





Expert systems 





Real-time control 





Text processing 
Document processing 
Electronic publishing 

Hypermedia processing 
Video processing 
Document storage & retrieval 
Electronic mail 
Voice mail 
Enhanced telephony 
Shared screen teleconferencing 
Video teleconferencing 
Broadcast 


Computer conferencing 














User interface services 


System management services 


Communications management 


services 





Database management 
services 
Hypermedia 
Transaction media services 
Document management 
services 
Conferencing management 
services 
Distribution services 
Repository services 
Repositories for system 
construction 
Repositories for systems 
management 
Server definitions 
Name server 
Authentication server 
Access control server 
Cryptographic server 
Communications server 
Time server 
File server 
Data server 
Print server 
Mail server 
EDI translation server 
Applications server 
Presentation server 
Sensor monitor/ actuator 


server 
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GTP 
Intelligent Wide Area 
Network Systems 


Establishment-based 


Switching Systems 


Local Area Network Systems 


Enterprise or Corporate 


Processing Systems 


Divisional or Departmental 


Processing Systems 


Desktop or Portable 
Intelligent Workstations 















1. Requirements VS. Technical Capabilities VS. Sites 

Once the functional requirements for the users systems have been 
determined, they must be matched to the technical capabilities necessary 
to provide them. A matrix of Functional Requirements/Technical 
Capabilities should be developed. An example of such a matrix can be 
seen in Table 4. An “X” placed in the column of a requirement and the 
row of a technical capability signifies that the technical capability must 


be provided if the functional requirement is to be met. 


Functional aha ake (Fn)/Technical Capability iia Table 


~ Functional Requirements €n.., Sea 





Table 4: Functional Requirements/ Technical Capabilities Matrix 


At the same time, a matrix depicting the relationship of technical 
capabilities and enterprise sites should be constructed. A suggested 
symbol configuration can be seen in Figure 12. With this configuration, 
we can tell at a glance what category of functionality has been called for 


and what is the earliest year for implementation. 
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TCn 


a:b-c 


TC: technical capability designator 


: the assigned TC number 

: the highest functionality category of the TC 
(i.e., 1, 2, 3) 

: the earliest year the TC is required; for the highest 
level of functionality 

: the earliest year the TC is required for lower level 


of functionality (if earlier than b) 





Figure 12: Symbol Configuration Representing Technical Capability 


Table 5 illustrates the Site/Technical Capability Matrix. The 
technical capabilities inherit their functionality categories and 
implementation year designators from the functional requirements with 


the highest assigned functionality category they correlate to. If the date 


Site (S)/Technical Capability (TC) table 


eee eee 





 TCnj.08.96 


Table 5: Site/Technical Capability Matrix 


65 


of a lower category is earlier than the higher category, a second year 
designator is added to the symbol. 

For example, TC2 has a category one requirement for “98,” but it 
also has a category two date for “95.” Therefore, the complete symbol 
would be “TC2}:98-95.” Note that if the functionality is category one, the 
date can only be moved earlier; if it is category two or three, the 
implementation date is negotiable either earlier or later. Instead of filling 
the correlation box with an “X,” the box is marked with the date chosen 
for implementing that technical capability at that particular site. These 
dates can be changed in order to come up with the most cost-efficient 
implementation schedule (depending upon functionality requirements 
and network implementation. 

The purpose for these matrices is to help the design team, users, 
and reviewers track the required functionality and technology in a 
systematic manner. It simplifies the process of documenting which 
functional requirements drive which technical capabilities and at what 
sites the technical capabilities are required. It will assist in tracking how 
many equipment suites must be planned for and how much space will be 
necessary at each particular site. 

Once the above process has been completed for the users systems, 
the same type of matrices should be constructed for the 
telecommunications network. These will be very useful to all those who 
participate in the functional/technical dialogue and assist the design 


team while dealing with system migration during the next two phases. 
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E. THE BACS TARGET ARCHITECTURE 


1. Organizational 

With the new CG streamlining measures coming into effect [Ref. 
12], the BACS design team has it is job cut out. Many of the missions, 
functions, and workflows for a number of the BACS user commands will 
be affected (i.e., growth of MLCP, dismantling of D11, new PACAREA 
responsibilities, etc.). 

Because the streamlining measures are causing changes in the 
“system,” the BACS project has actually come at an opportune moment. 
As we discussed in chapter one, one biggest stumbling block to 
implementing change is overcoming the resistance. In this case, the 
“system” is already facing mandatory change. With the investment of 
some resources, PACAREA and MLCP have the perfect opportunity to re- 
engineer some of the more ineffective or inefficient workflows. This could 
lead to much greater savings in the future. 

Even if the command structure does not take advantage of this 
opportunity, the design team must still re-evaluate the 
telecommunication needs for each of these units. This is critical if they 
are to design a network capable of serving this newly organized 
enterprise, today, and into the future. 

There is the possibility the BACS network could be used by other 
government agencies. Many of the remote sites are located next to 
equipment owned by the Navy, Forest Service, Federal Aviation 
Administration, and others. These agencies should be spoken with 


before the project gets too far into the planning stage. 


2. Functional 
The BACS network is a very large, complex project. The required 


functionality of the different user commands covers the scale from one 
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end to the other. Due to this size and complexity, the project officer 
should implement a procedure, like the procedures suggested above, to 
track and document the project. 

The opinions on the required level of functionality vary in the same 
way. Because the political level of functionality is above that of the 
project officer, he must assume the role of facilitator. He must 
encourage dialogue and lead the entities involved to a consensus. The 
group must be willing to explore new possibilities and work together for 


the good of the whole enterprise. 


3. Physical 

With all the recent changes in the telecommunications industry, 
we must be careful not to lock ourselves into a given technology or way of 
doing business because “that is the way it is always been done.” If this 
occurs, we will be limiting our opportunities to take advantage of the 


before-mentioned advances. 


F. CONCLUSION 


By using the Structured Approach Model, we have systematically 


completed the following: 


1. We have considered the CG-wide visions and strategy for which 
our project can help, or hinder, implementation. 


2. We have defined the problem by listing the visions and 
operational requirements which cannot be met by the system 
along with any existing limitations or discrepancies with the 
physical structure which justify replacement. 


3. We have drawn a limited picture of “where we are” with respect 
to user systems by inventorying the physical sites and 
resources, studying work-flow patterns, and collecting user 
requirements. We have drawn the same kind of picture for the 
existing telecommunications network by inventorying the sites 
and resources, studying the existing circuits and network 
management techniques. 
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4. We have determined “where we want to go” by attempting to 
collect future requirements, by considering possible changes to 
organizational structure and business processes, and by 
determining a standards-based system architecture that can 
meet the functional requirements independent of a specific 
technology implementation. We have also developed a matrix 
that correlates the functional requirements with the technical 
capabilities required to implement them and a matrix that 
correlates the technical capabilities to the sites (correlates 
technical capabilities for both the user systems and the 
telecommunications network). 
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VI. GENERAL COMMUNICATION 
SERVICES & TECHNOLOGIES 


A. INTRODUCTION 

The purpose of this chapter is to review some of the basic 
communication services, protocols, and technologies available today. To 
complete the target architecture, the design team must have an 
understanding for the technology that is available today and where 
technology is headed tomorrow. They should possess a working level 
understanding of the existing de jure standards and the architectures 
which form their foundations. 

This chapter provides a broad discussion of basic communications 
engineering concerns and some of the more prevalent architecture 
standards and transmission media available today. 

The block diagram of a general communication system is given in 
Figure 13. The basic problem faced when designing a communication 
system can be viewed from two different aspects. These two views 


include designing a communications system that: 


1. Uses a given transmission channel as effectively as possible. 
This means that the channel should convey the maximum 
possible amount of information in the time permitted, 
consistent with the noise introduced and the error in the 
received message that can be tolerated {Ref. 14]. This view deals 
with channel effectiveness. 


2. Provides the most economical channel to use with the given 
message, consistent with the noise sources and the allowable 
error rate. The choice of the method of coding, as well as the 
design of all the components in the coder, channel, and 
decoder, must be considered to overcome these limitations. 
This view deals with channel efficiency. 
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In this diagram we can introduce either a wired or wireless system 
in the transmission channel as a means of transmission interconnection. 
Telephone lines are an example of a wired interconnection, while cellular, 


microwave, and satellite systems are examples of wireless systems. 
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B. THE BASICS OF COMMUNICATIONS 

In any communication system information to be transmitted is 
generally available in the form of an electrical signal that may take one of 
two forms: an analog or a digital signal. In the analog case, the signal 
(e.g., electric current) varies continuously with time, as shown 
schematically in Figure 14(a). In the case of a digital signal, the signal 
will normally have one of two (and sometimes three) voltage values. 
These values represent the digital bits "0" and "1" (bit stands for binary 
digit), as shown schematically in Figure 14(b). 

An analog signal can be converted into digital form by sampling it 
at regular intervals of time. Communications by digital signaling is an 
increasingly important technique for radio communications. With the 
exception of slow (below 56 Kbps) dial-up circuits using modems, most 


WAN connections use digital transmission. Therefore, this discussion 
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Figure 14: Representation of a) an Analog Signal & b) a Digital Signal 
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will focus on digital transmission techniques. 


Digital transmission has a number of advantages over other 


techniques [Ref. 15 ]. These include : 


Lis 


the ease and efficiency of multiplexing multiple signals or 
handling digital messages in "packets" for convenient switching; 


. the relative insensitivity of digital circuits to re-transmission 


noise, commonly a problem with analog systems; 


. potential for extremely low error rates and high fidelity through 


error detection and correction; 


communications privacy; 


. the flexibility of digital hardware implementation, which permits 


the use of microprocessor, digital switching, and the use of 
large-scale integrated circuits. 


Digital transmission techniques require an analog-to-digital 


interface (or vice-versa) when the original form of the information 


transmitted is analog. 


There are three basics required for data communications [Ref. 16]: 


1. 


. a physical connection; 


. a set of data communication functions performed by 


participating computers; 


use of common protocol for each communication function. 


Physical Connection 


Physical connections can be provided over many types of 


transmission media (e.g., twisted pair, coax, microwave). Connections 


are made either over a dedicated link or through a switched network. 


Types of networks will be discussed further in section b4-b7. 
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2. Communication Functions 

The following are communication functions which must be 
performed by participating network computers: 

1. information encoding; 

2. encryption/compression; 
3. session management; 
4 


. error and flow control - from originating point, across 
network(s), to destination 3; 


5. interaction with network; 
6. error and flow control - across each link between nodes; 


7. bit encoding. 


Due to the complexity of implementing the above functions, 
standard data communication architectures have been developed to 
decompose these functions into more manageable modules and define 
interaction between the modules. The four standard architectures 


include: 
1. IBM’s System Network Architecture (SNA) - proprietary; 
DEC’s Digital Network Architecture (DNA) - proprietary; 


ISO’ Open Systems Interconnection (OSI) - open standard; 


pe Gor 


DOD’s TCP/IP Architecture - open standard. 


This discussion will focus on the open standard network architectures 
(i.e., OSI, TCP/IP) since these are the standards used widely by the U. S. 


government. 





3 These are unnecessary for dedicated connections. 
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Each of the communication functions mentioned above are 


contained within one of the layers of each architecture. This can be seen 


in Table 6. Each architecture layer uses protocols to specify how the 


functionality is to be provided. 


Table 6: Association of Communication Functions with Architecture Layers 





OSI Architecture 


Layer 7: Application 


Layer 6: Presentation 
Layer 5: Session 


Layer 4: Transport 


Layer 3: Network 


Layer2: 
Data Link Layer 


Layer1: Physical 


3. Protocols 





Communication 
Function 








Information Encoding 
(specific applications; 
such as Email, File 
Transfer, etc.) 


Encryption /Decryption 
Session Management 


Error and Flow Control 
(across networks) 


Interaction with 
Network 


Error and Flow Control 
(across a link) 


Bit Encoding 





DOD’s TCP/IP 
Architecture 


Layer 4: Upper Layer 


Layer 4: Upper Layer 


Layer 4: Upper Layer 


Layer 3: 
Transmission Control 


Layer 1: 
Network Access 
& Layer 2: Internet 


Layer 1: 
Network Access 


Layer 1: 
Network Access 














Standards (also known as protocols) based on the OSI architecture 


are developed by a voluntary group called “International Standards 


Organization (ISO).” These standards are then massaged and given 


formal authority by the International Consultative Committee on 


Telegraphy and Telephony (CCITT), which is part of the United Nations. 
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The OSI architecture consists of seven layers. The networking protocols 


are contained within the first four layers. 


The United States Department of Defense (DOD) developed the 


TCP/IP network architecture. It consists of four layers. The networking 


protocols are contained within the first two layers (these correspond to 


the first four OSI layers). The OSI and TCP/IP architectures are 


compared in Figure 15. 


Each layer has specific protocols for specific purposes. For 


example, EIA 232-D can be used for the OSI physical layer. This 


protocol defines the following five things: 


Ls 


electrical: uses NRZ-L bit encoding scheme; 


. physical connector: RS 232 25 pin connector; 


2 
3. 
4 


functional: assigns each connector pin a given function; 


. procedural: specifies what computing equipment will do when 


it has a task to complete or when it receives a given signal ona 
given connector pin; example: when the Data Terminal 
Equipment (DTE) has data to send it will apply high voltage 
(<3V) on pin #4, when the Data Circuit-terminating Equipment 
(DCE) receives high signal on pin #4, it acknowledges with a 
high signal on pin #5. 


. constraints: distance between DTE and DCE is limited to 


approximately 50 ft (15m); limit of 20Kbps between DTE and 
DCE. 
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Example TCP/IP Examples 
of shared Architecture of TCP/IP 
protocols protocols 
X.400 & 
X.500 FTP, 
(with adjustments) SMTP, 





6) Presentation Telnet 


ISO 8062, | 


ISO 8073: | 
| 4) transport 
TP classes | pane 


TPO-TP4 | 


ISO 8473: CLNP Internet 
3) Network 





ISO7776:HDLC | 2) Data Link ISO 
X.25} 1.221 | 8802 
(LAN) 








7 layers 4 layers 





Figure 15: OSI & TCP/IP Architectures with Examples of Associated Protocols 


There are also protocols which span across architecture layers. 
These protocols are for specific types of networks and incorporate various 
protocols from each layer. For example, X.25 spans the physical layer, 
data link layer, and half the network layer of the OSI model. It consists 


of the following protocols at layers 1-3 [Ref. 16]: 


1. Layer 3: X.25 Packet Layer Protocol (PLP); 
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2. Layer 2: Link Access Protocol “B” (LAP-B); 
3. Layer 1: X.21 or EJA 232-D. 


Some of these protocols can be applied under either architecture. 
X.25 is a good example. If X.25 is used with the TCP/IP model, protocols 
for the internet, transmission, and upper levels would be applied. If X.25 
is used with the OSI model, the CLNP protocol is applied to complete the 


network layer, then protocols for layers 4 - 7 are applied. 


4. Types of Communication Networks 

So why are there so many protocols? The protocols chosen to 
perform the functions of the different layers depend on the type of data 
sent, the type of network used to send it, and the method for completing 
each function that the engineer considers best for the situation. Since 
the protocols dealing with the telecommunications network are contained 
within the first four OSI levels (first two TCP/IP levels), we will limit the 
following discussion to those levels. Sections b5 - b8 correspond to the 
first four layers of the OSI model; they briefly describe: 1) the different 
types of circuits and 2) the methods for implementing the 


communications functions assigned to that architecture layer. 


5. Physical Layer 

As discussed earlier, there are two types of data: 1) analog, and 2) 
digital. The analog data can come from an analog source (i.e., voice, 
multimedia) or it can be digital information converted to analog by a 
modem. Analog data can only be carried on broadcast networks. Recall, 
these are networks which contain fixed, or dedicated, paths from sender 
to receiver. Digital information can come from a digital source (e.g., 


computer, ISDN telephone) or can be analog information that has been 
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digitized. Digital data can be carried on either broadcast or switched 
networks. 

To compensate for loss of signal strength over long distances, 
analog circuits normally contain amplifiers at intermediate points to 
boost signal strength. In addition to boosting signal strength, the 
amplifiers also boosts any noise that has been introduced to the signal. 
As the signal travels from amplifier to amplifier, more noise is 
introduced, and subsequently amplified. This leads to a drop in the 
Signal-To-Noise ratio, a measurement of signal degradation. Digital 
circuits incorporate repeaters instead of amplifiers. As long as the digital 
signal is strong enough to recognize the individual bits are recognizable, 
the repeater regenerates the signal faithfully and sends it on. This 
prevents any noise introduced to the signal from being passed on from 


link to link. 


6. Data Link Layer 

The Data Link Layer is responsible for reliable transmission of data 
across a single switched network link, or from point-to-point across a 
broadcast network. There are three controls that lead to reliability: 

1. error control; 

2. flow control (at message level); 


3. access control (at network level). 


We will discuss various methods used to apply error and flow control. 
Access control applies mainly to LAN’s; therefore, it is beyond the scope 
of this paper. 

There are three types of error detection used in the DLL: 1) Parity 
Check, 2) Two-dimensional Parity Check (LRC and VRC), and 3) Cyclical 
Redundancy Check (CRC). To provide error and flow control, the signal 


binary bits must first be packaged with the overhead bits into frames. 
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There are three frame formats, depending on what the signal data is 
oriented to: 1) Asynchronous, 2) Character-oriented Synchronous, and 3) 
Bit-oriented Synchronous. Figure 16 (a, b, c) depict the various 


segments of each type of frame. If an error is detected, re-transmission 


of frame is requested. 


ts ui aed 


FRAME 






a) Asynchronous 








Sync. Char. | Control Char. Data Char. (mulitples of 8 bits) Contro! Char. Syne. Char. 


FRAME CHECK SEQUENCE FRAME CHECK SEQUENCE 









b) Character-Oriented Synchronous 





011011001 Data Field (any number of bits) | Control Field 011011001 


rol Field. 
‘3 FRAME CHECK SEQUENCE FRAME CHECK SEQUENCE T 


Pre-Defined Sequence) (Pre-Defined Sequence) 
c) Bit-Oriented Synchronous 
Figure 16: Frame Formats for Digital Signals 






There are two methods used for flow control: 1) Stop & Wait, and 2) 
Sliding Window. Under the Stop & Wait method, the sending DTE sends 
one frame and waits for the receiving DTE to send a “received” 
acknowledgment. Once the acknowledgment is received by the sender, 
the sender will send the next frame, and so on. The Sliding Window 


utilizes a First-in/First-out (FIFO) buffer in the receiving DTE. The 
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sending DTE begins sending frames, not waiting for “received” 
acknowledgments. The “window” is the number of frames the sending 
DTE will send out before stopping and waiting for “received” 
acknowledgments to return. As the receiving DTE receives the frames, 
they are placed in the FIFO buffer. As the receiving DTE processes the 
frames, it sends acknowledgments back to the sender. If more frames 
arrive than the buffer can hold, they are automatically discarded. The 
sending DTE will send the number of frames specified for the “window.” 
If it still has not received acknowledgment for the first frame in the 
window, it will time-out and automatically re-send that frame. 

If an acknowledgment is lost, the sender will continue to send 
frames until the “window” limit is reached. It will then time-out and 
automatically re-send the unacknowledged frame. When the receiving’ 
DTE receives the same frame a second time, it will send a second 
acknowledgment, then throw away the frame (since that particular frame 
was already processed the first time it was sent). 

If the receiving DTE detects an error (using parity or CRC 
checking), it will pass the frame back to the flow control. This will cause 
a negative acknowledgment to be sent back to the sending DTE. Upon 
receipt of the negative acknowledgment, the sending DTE will re-send the 
frame. 

There is one more set of optional methods that can be applied 
under the “Sliding Window” method. These methods are called “Selective 
Repeat,” and “Go Back-N.” Anytime the receiving DTE has to send a 
negative acknowledgment, the following will occur under the two 
methods: 

1. Selective Repeat - The receiving DTE will keep all additional 


frames it receives until the bad frame is received correctly 
(provided the buffer has enough room). 
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2. Go Back-N - Once a negative acknowledgment has been sent, 
the receiving DTE will dump all incoming frames until the bad 
frame is received correctly. 


Anytime the sending DTE times out, the following will occur under 
the two (sub)methods: 
1. Selective Repeat - The sending DTE will re-send only the frame 
that caused it to time-out. The receiving DTE will keep all 


additional frames it receives until the frame causing the time- 
out is received. 


2. Go Back-N - Once the sending DTE times out, the sending DTE 
will begin re-sending all frames, beginning with the frame that 
caused the time-out. If the receiving DTE had received all the 
frames, it will dump them the repeated frames the second time 
they are received. 


Table 7 summarizes the available Frame Format/Error 
Control/Flow Control combinations. As an example, the OSI’s High-level 
Data Link Control (HDLC) uses the following combinations: 

“HDLC => Bit-oriented Synchronous — CRC — Sliding Window.” 


Table 7: Data Link Layer Frame Format/Error & Flow Control Combinations 


Asynchronous Parity bit Stop & Wait 


Character-oriented Synchronous Stop & Wait 
LRC or CRC or 

Sliding Window 

Bit-oriented Synchronous Stop & Wait 


or 





Shding Window 








7. Network Layer 
This section is mainly edited and abbreviated from Ref. 16. As 


mentioned before, the communication functions contained within the 
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network layer are not needed for broadcast or dedicated networks. The 
network layer is responsible for interaction with a “switched network” 
(i.e., circuit-switched, packet-switched, or fast packet-switched network) 
or a group of networks. The protocols contained within the network layer 


define: 


1. the format of messages (or packets) deliverable across 
network(s); 


2. how each message (or packet) format incorporates “connection- 
oriented” or “connectionless” network services; 


3. which message (or packet) formats initiate and terminate 
network connections; 


4. what each message (or packet) format does when messages (or 
packets) are lost or damaged within the network (i.e., error and 
flow control across the network). 


After defining how “connection-oriented,” “connectionless,” and 
“fast-packet switching (FPS)” network services interact with networks, 
this section will discuss the various message (or packet) formats 
including their benefits and constraints. We will then use the X.25 
protocol to illustrate how the sub-protocols (protocols contained within 
different levels of the X.25 protocol) apply the characteristics of the 


packet format and network service. 


a. “Connection-oriented” VS. “Connectionless” Service 

The two types of switched networks consist of “Connection- 
oriented” and “Connectionless.” Both services share one trait, both use 
what is called “store and forward” message delivery. This simply means 
that the message, or packet, is passed from network node to network 
node; at each node, the message (package) is stored in either memory or 
on disk until the node can transmit the message (package) on to the next 


node. 
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Connection-oriented service is also known as “virtual circuit 


”» 


service.” This network-layer service goes through three stages: 1) 
establishes connection, 2) transfers data, and 3) disconnects connection. 
Rather than establishing a dedicated circuit, it establishes a “logical 
circuit”; this means that all the data packets will pass through the same 
nodes until finally reaching the destination. This type of service does the 


following: 
1. it assures that the packets will arrive in the same order as sent; 


2. it allows the network nodes to request re-transmission as soon 
as a packet is lost or damaged; 


3. the nodes can pass the packets to the next node faster because 
it does not have to strip the frame from the data and repackage 
it in a frame containing the next node address; 


4. it allows other data from various sources, to use the same lines; 
thus providing greater line efficiency. 


Connectionless services come in two flavors: message- 
switched and datagram. Connectionless services do not use the same 
path for an entire session like the connection-oriented. Instead each 
node makes a decision based on information it receives from the | 
surrounding nodes. Each node chooses the “least cost” node out of the 
nodes that are available. The network control center decides which node 
is the best alternative (least-cost). This decision-making has nothing to 
do with the network layer. 

The message-switched service passes the whole message at 
one time. Once the message is received at a node, it is temporarily 
stored on disk and then passed on to the next available “least-cost” node. 
Since messages can vary to practically any length, the delay at each node 


(consisting of receiving time plus queuing delay time) will be relatively 
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long and highly variable. This makes message-switching inappropriate 
for real-time or interactive systems. 

Datagram services send packets of data; they also limit the 
size of each packet. This, in turn, limits the delay experienced at each 
node. The packets are small enough to be stored in memory rather than 
on disk. However, since each packet is sent to the next “least-cost” node, 
and does not follow a given route, the packets can arrive at the 
destination out of order. Table 8 sums up the differences between the 


connection-oriented and connectionless services. 
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Table 8: Network Layer Services Summary 

















circuit-switched 
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data transfer 
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route for each package 
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(using control packet) 
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b. Fast-Packet Switching (FPS) Services 

Fast-packet switching (FPS) services are connectionless 
services that utilize permanent virtual circuits (PVC) established by the 
network manager. FPS includes both frame-relay and cell-relay 
technologies. They are designed for high throughput and low traffic 
delay while retaining the efficient line-sharing of regular packet- 
switching networks. The high throughput and low delay is accomplished 
by stripping some of the protocol processing out of the service. FPS does 
not provide any network link-to-link error or flow control. Due to the 
high speeds at which information is delivered using FPS, it is more 
efficient to allow the network layer at the DTE to request a re- 
transmission, rather than check each message at every link. 

The two basic types of FPS include “frame relay” and “cell 
relay.” The basic difference between the two is the length of the packet. 
The frame relay allows for variable length packets while cell relay 
standardizes the packet (in this case called a “cell”) length at 53 bytes. 
By using a standardized cell size, cell relay can implement hardware- 
based switching. Hardware-based switching can occur much faster than 
software-based switching. Because of the variable frame size, frame-relay 
must use software-based switching. Frame relay can provide service up 
to 1.5 Mbps, while cell relay can provide up to a minimum of 2.5 Gbps. 
However, due to the small 48-byte data package contained in each cell, 
cell relay has a much higher overhead (~10%) compared to frame relay 
(~0.33% - 4%). 

“As a general rule, the lower the speed (e.g., T1 and sub T1), the more 

concerned you are with overhead for data applications...At levels of T3 and 
above, the benefits of ATM outweigh the efficiency considerations. At 


relatively lower speeds ( T1 and below), frame relay more efficiently transports 
data.” [Ref. 17] 
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c. The X.25 Protocol 

We will use the X.25 protocol to show how network layer 
protocols are made up of sub-protocols to interact with the underlying 
layers. The X.25 protocol is a connectionless, virtual circuit, packet- 
switching protocol. 

At the network layer (layer 3), X.25 consists of the X.25 
Packet Layer Protocol (PLP). The X.25 PLP defines the necessary packet 


formats, such as the data and control packets. It also defines: 


1. what control packets are exchanged in order to establish or 
disconnect a virtual circuit; 


2. a sliding window for error and flow control. 


At the datalink layer (layer 2), X.25 consists of the LAP-B 
(Link Access Protocol; a subset of HDLC) protocol. This layer provides 
the link-to-link error & flow control for the virtual circuit. At the physical 
layer (layer 1), X.25 consists of the X.21 layer 1 protocol (or EIA-232-D). 


We covered this protocol back in section B-3. 


8. Transport Layer 
The transport layer provides error control at the network level. It 


also consists of connection-oriented and connectionless services. 


a. “Connection-Oriented” VS. “Connectionless” Service 

Connection-oriented transport services establish, maintain, 
and terminate the logical connections between transport users. They 
also ensure reliable end-to-end sequenced delivery and error & flow 
control. 

The ISO transport protocol for connection-oriented is known 
as “ISO TP (or ISO 8073).” There are five different classes of TP available, 


each providing different levels of error control. They are as follows: 


1. class 4 (TP4) error detection & recovery; 
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2. class 3 (TP3); 
3. class 2 (TP2); 
4. class 1 (TP1) basic error recovery; 


5. class 0 (TPO) simple class. 


ISO TP-4 is functionally identical to the DOD TCP standard. 

The connectionless protocol is “ISO 8062.” This protocol is 
used by applications that favor speedy handling over reliability; they do 
not need reliable transmission of messages. ISO 8062 corresponds to 


the DOD UDP standard. 


9. Conclusion 

In this section, we have reviewed some of the basics of 
communications to assist the design team in understanding the origin 
and purpose of various protocols. It is hoped that this section will be a 


useful reference. 


C. MICROWAVE SYSTEMS 
In a microwave system, the transmitting and receiving equipment 
must be designed for the frequency selected, for the given transmission, 


and for the bandwidth required [Ref. 14]. 
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A microwave system consists of end sites and relay sites, as 
illustrated in Figure 17. A simplified illustration of a typical relay 


station, as part of the transmission channel, can be seen in Figure 18. 


Relay Stations 








ren (em THH{apH I Hz) Receiver 


/\ /\ 


END SITE RELAY SITE 











Figure 17: Microwave Relay Block Diagram 


The basic function of the relay link is to receive the wave from the 
preceding station, amplify it by the desired amount, and radiate it toward 


the next station. 
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Figure 18: Simplified Microwave Relay Component Diagram 


A microwave site, of course, is not as simple as these diagrams 
portray. The system design will have to consider an interplay among a 


number of factors The following are some examples : 


1. In selecting a carrier frequency, the higher this frequency, the 
greater the bandwidth that can be obtained for the channel and 
the smaller the antennas for a given antenna gain. However, 
the efficiency and reliability of available amplifiers is lower. At 
too high a frequency, atmospheric and rain attenuation may 
also occur along the propagation path. 


2. The larger the antennas for a selected carrier frequency, the 
greater the antenna gain. This permits either lower 
amplification at each station or a greater station spacing for a 
given amplifier. However, large antennas with a large wind 
loading increase the cost of each station; thus these advantages 
and disadvantages must be balanced. 


3. The use of tall towers or selection of station locations on high 
mountains offers the best propagation possibilities. This may 
permit greater station spacing or less expensive repeater design. 
However, it may increase the cost of construction or 
maintenance of the station. 
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4. Using wide bandwidth channels permits greater signal 
multiplexing or lower signal-to-noise ratios, hence greater 
station spacing, up to a certain point. The design of very 
broadband amplifiers and other components becomes 
expensive, and noise figure may decrease the signal strength 
faster than the bandwidth improves it. Thus, a parallel link may 
be a better solution for increasing channel capacity beyond a 
certain point. 

In the design problem, interrelations among transmitted frequency, 
antenna size, transmitted power, receiver noise figure, and 
characteristics of the propagation path are again important. Pulse width 
and repetition rate offer two additional variables to the equation. 

One of the alternatives for BACS is the use of higher frequency 
digital microwave system. For this purpose, a number of factors must be 
examined to understand the affects of a higher frequency. 

From a general standpoint, the design of a general microwave link 


requires performing an iterative sequence of the following steps : 
1. Path and site selection; 
2. Propagation and interference; 


3. Selection of equipment capable of satisfying the availability 
objectives set for the route; 


4. Final calculations. 


The microwave beam behaves much like a light beam as far as 
atmospheric influences are concerned. It is also subject to other external 


influences as described in the following discussion. 


1. Influence of Terrain and Obstructions 

The microwave beam is influenced by the intermediate terrain 
between stations and by obstacles. It tends to follow a straight line in 
azimuth unless intercepted by structures in or near the path. In traveling 


through the atmosphere it usually follows a slightly curved path in the 
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vertical plane, i.e., it is refracted vertically due to the variation with 
height in the dielectric constant of the atmosphere. Generally, this 
refraction is slightly downward, so that the radio horizon is effectively 
extended. The amount of this refraction varies with time due to changes 
in temperature, pressure, and relative humidity. These control the 
atmospheres dielectric constant. 

The beam can be reflected from relatively smooth terrain and water 
surfaces, just as a light beam is reflected by a mirror. This occurs 
mainly at small angles of incidence. A good illustration of this can be 
seen in the case of an asphalt highway. When viewed directly, the surface 
looks slightly rough and does not reflect light well; however, when viewed 
from a distance at a very small angle, it looks like a mirror or wet 
surface. 

An important concept in analyzing microwave propagation effects, 
particularly those of diffraction, refraction, reflection, and the effects of 
terrain and obstructions, is that of the Fresnel zone. The first Fresnel 
zone radius is a kind of "rubber" unit, which is used to measure certain 
distances (path clearances in particular) in terms of their effect at the 
frequency in question, rather than in terms of feet. The second and 
higher order Fresnel zones are also very important under certain 
conditions, such as highly reflective paths. 

Although a microwave beam is conventionally shown as a line, the 
actual method of propagation is as a wave front, and the important 
portion of the wavefront involves a sizable transverse area. 

In order to ensure free space propagation, it is essential that all 
potential obstructions along a path are removed from the beam 
centerline by at least 0.6 F1 , where F1 is the radius of the first Fresnel 


zone at the point of the obstructions. 
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Because refractive bending varies in cycles daily and changes 
erratically at times, the clearance over the intermediate terrain must be 
adjusted to minimize the losses during extreme bending conditions. This 
calls for a path clearance over immediate objects somewhat greater than 
line-of-sight. Normally, the beam is bent downward by atmospheric 
refraction. Though, at times, the atmospheric conditions may be such 
that the beam is bent upward, effectively reducing the clearance over 


terrain in the path. 


2. Fading 

Fading is a general term applied to loss of signal as seen by the 
radio receiver at its input. The term is intended to apply to propagation 
variables in the actual radio path. 

The actual fading is the change in path loss between the 
transmitter at one station and its receiver at the following station. These 
changes in path loss have to do with atmospheric conditions and the 
geometry of the path. 

The effect of fading on radio paths is much greater than the 
attenuation variables of open wire and cable carrier systems, which are 
primarily due to the effect of temperature variations in the metallic 
medium. Radio fading is caused by refractive, diffractive, and reflective 
effects in connection with the atmosphere and fixed objects. Fading can 
result in defocusing, blocking, and sometimes cancellation from multiple 
paths of varied lengths, due to the resultant variation in phase angles on 
arrival at the receiving antenna. 

Although the atmosphere and terrain over which a radio beam 
travels have a modifying effect on the loss in a radio path, there is, fora 
given frequency and distance, a characteristic loss. This loss which is 


known as the free space loss increases with both distance and frequency. 
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The source of greatest loss in a typical radio transmission path is free- 
space loss (FSL) resulting from the propagation of the transmitted signal of 
frequency (Fy) over the distance (D) in statute miles between EIRP and 
receiving antennae.[ref. 18, p. 11]. 


Changing from 2Ghz to 8Ghz can have a great affect on the FSL. 


For example, the existing microwave 


Table 9: Fut VS FSL Loss at 38mi. 


shot from Monterey to Mount 
Umunhum is 38.06 miles. As we can 
see in Table 9, the average loss from 
changing to 8GHz is 12.1 dB. [Ref. 
18, p. 11] 

This loss, in addition to the 








other variables, indicates the current site locations within the BACS 


system must be re-evaluated for operation at the higher frequency. 


3. Atmospheric Effects 

For frequencies below about 100 GHz, attenuation caused by 
snow, hail and fog can generally be expected to be significantly less than 
rainfall attenuation for most regions of the earth. Under this 
circumstance, design considerations for fading margins required for 
precipitation attenuation can be based on rainfall statistics alone [Ref. 
19}. 

Attenuation of microwave signal due to rainfall along the path is 
present to some degree at all microwave frequencies. At higher 
frequencies the excess attenuation due to rain increases rather rapidly 
and, in the bands above about 10 GHz, is great enough to significantly 
affect path length criteria, except in areas of very light precipitation 
[Ref. 20] . 

The degree of attenuation is a function of a number of variables 


including the frequency band, size and shape of the drops, and the 
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distribution of rain (in terms of its instantaneous intensity) along the 
path. What is important is not the total amount of rain which falls over 
an extended period, but rather the maximum instantaneous intensity of 
fall which is reached at any given moment, and the size of the area over 
which the high intensity cell extends at that moment. 

The San Francisco Bay Area average monthly rainfall statistics is 
given in Table 104. This figure reveals that the rainfall is quite intense 


during the winter season. 


Average Monthly Rainfall 


San Francisco Bay Area 




















Table 10: Average Monthly Rainfall in San Francisco Area 





4 Courtesy of the San Francisco Weather Forecasting Service. 
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Two things to bear in mind in connection with rain attenuation 
are: (1) multipath fading does not occur during periods of heavy rainfall, 
so the entire path fade margin is available to combat the rain 
attenuation, and (2) neither space diversity nor in-band frequency 
diversity provide any improvement against rain attenuation. 

In practice, signal attenuation due to fog is usually modest 
compared with the attenuation rates for rain. On rare occasions, the 
liquid-water content can become as high as 0.5 to 1.0 g/m3 in very 
dense radiation fogs. Such fogs can be expected to produce attenuation 
rates comparable to those caused by rain 

Fog which occurs very close to the ground in the early morning, . 
usually in a valley immediately over a small stream, has quite another 
effect. In this case, the normal beam is in the clear, but the surface at 
the fog layer is a smooth strata which forms a good reflector of 


microwave energy [Ref. 19] . 


4. Site Selection 

Terminal sites are normally located at enterprise facilities. 
However, the relay sites are located with emphasis on propagation over 
the intermediate paths, and possible interference from internal or 
external sources. 

The choice of relay sites is greatly influenced by the nature of the 
terrain between sites. In preliminary planning it may be assumed that, in 
relatively flat areas, the path lengths will average between 25 and 35 
miles for the frequency bands from 2-8 GHz. Distances greater than 35 


miles between two sites may cause system degradation. 
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5. Equipment 

The characteristics of the microwave system components to be 
used affect the engineering choices and path performance parameters. 
Thus, the survey engineers must know in advance: 
frequency bands to be used; 
type of service (analog/ digital); 
number of channels (both present and future); 


performance and reliability criteria desired; 


ON Bt = Oo har oe 


parameters of the microwave equipment to be used (i.e., 
transmitter output power, receiver noise figure, bandwidth, 
etc.). 


Primary considerations during the selection of the microwave radio 
equipment include: 
1. Characteristic of the end-to-end baseband facility, including 


bandwidth, frequency response, loading capability, noise figure, 
and noise performance; 


2. The amount of radio gain available, as determined by 
transmitter power output and receiver noise characteristic; 


3. Operating frequency band, and required frequency spacing 
between radio channels, as determined by transmitter 
deviation, receiver selectivity, and frequency stability; 


4. Primary power requirements and options available; 


5. Supervisory functions available, including order wire, alarms, 
and controls; 


6. Equipment reliability, including availability of redundant 
versions such as frequency diversity, 1-for-N or 2-for-N multi- 
line switching, hot standby, or hot standby at transmitter and 
space diversity at receivers; 


7. Provisions for testing and maintenance. 


Towers have a significant effect on many microwave path 


engineering choices. Prior knowledge of the tower limitations is critical. 
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These include wind, , weight, and height limitations to name a few. The 
type of waveguide and transmission lines to be used is important, not 
only for their loss characteristics, but also for the degree of impedance 
matching attainable. This effects the echo distortion noise. 
Transmission line characteristics become extremely important with high 
density systems having long waveguide runs. 

The type and the size of the antenna that will be used depends on 
several variables. The most important ones are the gain, the area of 
antenna aperture, and the wavelength at operating frequency. The 


existing tower must also be considered. 


6. Propagation and Interference 

The final objective for any microwave system is to provide the most 
cost-efficient, distortion-free, and interference-free service continuity for 
the type of service assigned. Overall reliability, or service continuity, 
involves not only equipment failure rates and power failures, but also the 
propagation performance of the individual paths. This involves antenna 
sizes and elevation, frequency or space separations in diversity systems, 
path lengths, and frequency attenuation relationships. It also includes 
fading margins which, in addition to path parameters, are affected by 
noise figure, transmitter power, and attenuation of waveguide, and filter 
arrangements. 

Distortion may occur in the radio path, but more often it occurs 
due to poor return loss of amplifier components, waveguide filters, and 
antennas. Also the characteristic of switching devices and/or combiner’s 


are involved [Ref. 21]. 


101 


D. SATELLITE 

The satellites can be classified as "geostationary" or "low orbit" 
depending on their distance to the earth. The distance of geostationary 
satellites to earth turns out to be a disadvantage because of propagation 
delay. This delay is caused by the information traveling a minimum of 
45,000 miles before the data is received by the user facility. Large block 
sizes are used to improve efficiency. However, due to the delays 
encountered, recovery of errors in blocks of information becomes time 
consuming and costly. Therefore, the geostationary satellites are not 
suitable for applications that require very short response times. [Ref. 22] 

As an answer to this problem, several consortiums have planned 
extensive low-altitude, thus non-geostationary, satellite communications 
systems. These low-altitude orbits have a much shorter propagation 
delay, which is necessary for real-time duplex communication. These 
orbits also provide small propagation loss, allowing the use of low power 
and smaller satellites and earth station antennae. 

Most vendors offer three types of service: 1)channel-based, 2) 
carrier-based, or 3) leased services. Individual channels for services less 
than T-1 may be leased while wideband applications are normally 
purchased. 

The author has found two existing commercial satellite systems 
(Inmarsat and AMSC) and three other systems that are in various stages 
of development. Since Inmarsat has been operating since 1982, we will 
discuss it in some detail. We will then briefly discuss the other four 


systems. 


1. The Inmarsat System 
Inmarsat is an international organization operating the only global 


satellite system for mobile communications. The organization was 
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established in 1979, mainly on the initiative of the International 
Maritime Organization (IMO), with an initial mandate from its 
communications system to serve the maritime community by improving 
communications and the radio-navigation for safety of life at sea and 
efficient ship management. 

By convention, the Inmarsat space segment is open for peaceful, 
non-discriminatory uses by all nations, whether members of Inmarsat or 
not. The organization is required to provide services in all geographical 
areas where there is a need for mobile communications . Coverage now 
exists over the whole globe except the extreme polar regions. 

From Inmarsat's point of view, it is role is clearly divided into two 


main areas: 


1. providing the space segment for instant reliable distress and 
safety; 


2. a general satellite communications for the maritime community. 

Inmarsat has two major satellite communications systems 
designed to provide most of the medium and long range communications 
functions: Inmarsat-A and Inmarsat-C. Inmarsat also offers Inmarsat-E, 
and 1-band EPIRB system. 

The Inmarsat system, like most satellite-based communications 


systems, is comprised of three segments: 


1. the space segment; 
2. the ground control facilities; 


3. the end-user’s Mobile Earth Station (MES), also known as Ship 
Earth Stations (SES) in the maritime environment. 


a. Space Segment: 
The space segment is planned, procured, maintained, and 


operated by Inmarsat, and financed by the Inmarsat Signatories. 
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Inmarsat started commercial operations in February 1982 with leased 
satellite capacity from Comsat General, Intelsat and the European Space 
Agency (ESA). 

In 1982, Inmarsat launched its own satellite system 
composed of four satellites built by British Aerospace and Hughes 
Aircraft. Each of these new satellites has a total L-band EIRP of 39 dBw 
transmitted though a single global beam enough to support more than 
250 Inmarsat-A type channels. Each satellite was designed for a ten- 
year life mission in orbit and should be available for service well beyond 
the year 2000. 

In 1991, Inmarsat signed a contract with a consortium led 
by GE Astro and Marconi Space Systems to procure a first batch of four, 
third-generation satellites (Inmarsat-3). These represented the most 
technologically advanced mobile satellite developed at the time. Each 
Inmarsat-3 satellite has eight times the L-band power of an Inmarsat-2 
satellite (i.e., 48 dBw compared 39 dBw). In addition to global beam 
coverage, each Inmarsat-3 satellite provides coverage to four or five 
transmit-and-receive spot beams at L-band. The first of these satellites 


was scheduled for delivery in late 1994. 


b. Land Earth Stations: 

A worldwide network of gateway Land Earth Stations (LES), 
or Coast Earth Stations (CES) for maritime purposes, provide links for 
the end user, through the satellites, to the terrestrial public switched 
telecommunications network. LES are owned and operated by 
telecommunications authorities, mostly Inmarsat Signatories, which 


provide the mobile services to the end users. 
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Cz Mobile Earth Stations: 

The Mobile Earth Station (MES), Known as Ship Earth 
Stations (SES) in the maritime environment, are obtained from a number 
of manufactures and are commissioned by Inmarsat to utilize the 
system. 

At present, there are two families of Inmarsat satellite 
communications equipment available to mariners. Inmarsat-A is the 
larger and more versatile, offering voice, data, facsimile and telex-based 
communications. Inmarsat-C terminals are smaller and offer text and 


data messaging at lower speeds. 


2. American Mobile Satellite Corporation (AMSC) 

The AMSC was established in 1988 and has been licensed by the 
Federal Communications Commission to provide mobile satellite services. 
As Figure 19 shows, AMSC coverage includes most all of North America, 


extending approximately 200 miles out to sea. 


AMSC services are provided through one satellite in 
geosynchronous orbit 22,300 miles above the equator at 101° West 
Longitude. AMSC also has an agreement with a sister Canadian 
company for backup satellite coverage, in case of failure. The satellite 
uses six spot beams and 30 MHz of L-band spectrum to provide 


transmission coverage. Using the Ku-band, the satellite can receive 
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Figure 19: AMSC Maritime Standard Coverage Area 
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private network transmissions from anywhere in North America. This 
band is also used for the satellite uplink gateway located 14 miles from 
Reston, VA. A diversity uplink site is provided under an agreement with 
Washington International Teleport. The two site are connected by a full- 
time analog fiber optic circuit leased from Bell Atlantic. [Ref. 23] 

AMSC will offer voice, fax, and switched data services in the 


following four areas: 


1. satellite telephone service: consists of satellite-only telephone 
service; 


2. satellite roaming service: extends cellular services to all 
coverage areas. Subscribers place calls via cellular network 
when traveling in cellular coverage area. Outside of coverage 
area, calls are processed via satellite [Ref. 24, p. 6] ; 


3. fleet management services: in addition to above mentioned 
services, fleet management provides nationwide voice dispatch 
and position location services. These services are available to 
maritime, ground vehicles, aviation, and fixed sites. 


4. private network capacity: offers satellite capacity, switched 
service and network management to private network 
customers.. 


_ 


Prospective Satellite Projects 


a. The Iridium System: 

A consortium led by Motorola plans to launch 66 low-earth 
orbiting satellites as part of it is $3.4 billion Iridium effort; it is expected 
to provide 2.4 kilobit/sec data transmission to mobile users. [Ref. 25, p. 


S36] 


b. Teledesic System: 
A consortium led by Microsoft and McCaw Cellular plans to 
launch 840 low-orbit satellites delivering voice, data, and video services 


at speeds up to 16 kilobit/sec.[Ref. 25, p. S36] 
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c. GlobalStar System: ; 

Supported by Loral Corp., Qualcomm Inc., and PacTel Corp., 
Globalstar plans on launching 48 low-orbit satellites in 1998. At a cost 
of $275 million, they plan to offer data transmissions at 9.6 kilobit/sec. 
[Ref. 25, p.S36] 


E. WIRELESS TECHNOLOGY 

A wireless network providing alternative routing for the VHF 
National Distress System would provide the required duplexing features 
and could be an innovative approach. A standby cellular and satellite 
alternative routing system, such as the one illustrated in Figure 20, has 
been proposed by the American Mobile Satellite Corporation for 
alternative routing. In the event of leased-line failure, switching 
equipment would attempt to re-establish the VHF NDS link via the 
cellular network. If this link could not be established, the switching 
equipment would then re-establish the link using the AMSC satellite. 

Corporate owned cellular telephone systems operating in the San 
Francisco area theoretically encompass all the CG facilities in the area. 
Figure 21 shows the San Francisco Bay area coverage for Cellular One 
Inc.. This existing cellular system has numerous overlapping cells with 
emergency power services immediately available. Information concerning 
the actual operational availability of the individual cellular companies is 
treated as “corporate secrets”; they are, however, considered to be at 


least 99.5% [Ref. 26, p. 359]. 
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Red: Indicates local calling area. 
Orange: Indicates Cellular One North American Cellular N/W 
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A wireless telephone network could be quickly expanded during 
emergencies to facilitate the required communications between CG 
command centers and on-scene commanders. It could also be designed 
to aid in the relocation of command resources in the event of failures or 
during an emergency, such as an earthquake. 

Although this technology has never been used by the CG in this 


manner, the alternative deserves to be fairly evaluated. 


F. CONCLUSION 

The purpose of this chapter has been to review some of the basic 
communication services, protocols, and technologies available today. It 
is intended to give the design team an initial understanding of the 
technology that is available today and where technology is headed 


tomorrow. 


Although developed separately, many companies have developed 
interfacing schemes that allow various standards and transmission 


media to be integrated into a single WAN. 
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VII. SYSTEM MIGRATION 


A. INTRODUCTION 

This chapter covers phases five and six of the Structured Approach 
Model. In the fifth phase, “Develop Migration Candidates,” we will 
discuss the factors involved when developing a list of alternative 
migration paths that can be used to reach our target architecture. In 
phase VI, “Select Migration Path,” we will discuss some useful 
methodologies to help us determine the most cost-effective configuration 
from the list of alternatives and analyze our projects’ level of sensitivity to 
change. | 

In the previous chapters we used the three views to help us 
visualize aspects of the project we may have otherwise overlooked. In the 
author’s opinion, the “organizational” and “functional” views during these 
two phases mainly serve as “checklist” reminders. This reminds us to 
check that any changes to business processes, and that all functional 
requirements, are implemented within each alternative. On the other 
hand, the physical view begins to take form as we move from standards 
and technical capabilities into the actual details of alternative 
configurations. Therefore, our discussion of these two chapters will 


develop around the required tasks, rather than the views being used at 


the time. 





B. DEVELOP MIGRATION CANDIDATES 


1. Limiting the Number of Migration Paths Considered 

There are a number of factors that can be varied, each of which 
could affect the final network configuration. Some of the factors that can 
vary between possible candidates include: 

1. the level of functionality attained for “should have” and “nice to 


have” requirements (this goes for both the users systems and 
the telecommunications network); 


2. the timetable for implementing the various technical 
capabilities; 


3. the technologies used for implementation; this includes the 
users systems, telecommunications transmission media, and 
type of network management software chosen. 

The number of candidate migration paths is the product of the 


following equation: 





n 
¥ Variations 


X=(F,)1 


Where, 
X = number of candidate migration paths 
Fn = number of factors 
Variations = number of variations for each factor 











Equation 1: Migration Path Alternatives Calculation 


Each time a factor variation is added, the number of new candidate 
paths increases by a whole magnitude. Therefore, we must find ways to 


limit these variations. Dr. Emery states: 


114 


Since each alternative examined entails a certain amount of effort, the 
number must be limited to three or four substantially different alternatives. It is 
important, though, that they encompass a wide range of characteristics so that 
attractive options will not be overlooked. 

At the low end of the range, a bare minimum design should aim only at 
satisfying the “must have” user needs (with perhaps some of the more cost- 
effective “should haves” thrown in for good measure). A high-end system 
should meet most of the “should have” and many of the “nice to have” 
requirements. This wide range is quite likely to bracket the design that provides 
the best balance between cost and benefits. [Ref. 27, p. 232] 


Although any limitation increases the risk of overlooking the one 
optimal candidate path, by using common-sense and deliberation to 
make and apply assumptions, the design team should be able minimize 
both the factor variations and this associated risk. All assumptions 
made, including factors leading to the assumptions, should be recorded 
in the project folder. If there are no communicable reasons for reaching 
an assumption, record this fact. There is nothing wrong with this, as 
long as a consensus is reached. What is important is collecting and 
tracking the thought process behind the decisions; this is for team- 
learning, not for criticism. 

Some methods suggested for limiting the number of factor 


variations include: 


1. Limit Functional Requirement Variations: As suggested by 
Dr. Emery, above, the design team can begin by agreeing to two 
designs, one that lies at the low end of the functional scale, one 
at the high end. Once the cost-effectiveness analysis has been 
completed using these two designs, the design team can 
compare the additional benefits gained from the high-end 
configuration to the incremental costs between the two 
configurations. Depending on the outcome of the comparison, 
management can decide if the marginal return on the additional 
expenditure is equal to, or greater than, the marginal return of 
the best use of the additional resources. 


2. Limit Timetable Variations: The design team can agree to one 
initial timetable for implementing the various technical 
capabilities. Once a final configuration is agreed upon, the 


115 


implementation timetable can be re-evaluated to take advantage 
of any efficiencies offered by that particular configuration. 


3. Limit Technology Variations: A standards-based target 
architecture was developed in Chapter 5. The design team 
must choose a transmission media (including the component 
configuration to implement it) and a network management 
system that provides the optimal migration path to reach the 
target architecture. The available alternatives for each of these 
will be ranked later in this chapter using FOM. However, 
certain alternatives may be ruled out early using known 
limitations, or initial cost data. Using the BACS as an example, 
we know that analog microwave will not meet our set 
requirements as a transmission media. With minimal research 
effort, some available network management applications may be 
ruled out, due to costs or for lack of required network 
troubleshooting features. 


2. Specific Site Alternative Limitations 

The physical sites involved in most telecommunications projects 
vary greatly. Some of these variations will limit the technical alternatives 
available at particular sites. For instance, suppose that cellular links are 
being considered as a major contender for system redundancy. However, 
we assume (or know) that cellular capability is not available at 10% of 
the sites. Rather than throwing this in as another variation, it would 
simplify the process if we complete the cost-effectiveness analysis before 
considering these specific variations. Once the cost-effectiveness 
analysis has ranked our technical alternatives, and cellular has been 
chosen, we can consider altering our plans for specific sites to overcome 
any limitations. 

Limitations can affect scheduling, such as weather restricting site 
access to given times of the year. Other site limitations could include 
civil engineering aspects (e.g., building codes and restrictions, space, 
power), radio spectrum availability, utility access, and so forth. Unless 


these restrictions apply to a large percentage of the sites, they should be 
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considered after the initial cost-effectiveness analysis. The design team 
will have to decide the percentage of sites that must be affected before a 
restriction is allowed to effect the configuration used for the initial cost- 


effectiveness analysis. 


C. COST EFFECTIVENESS ANALYSIS 


1. Introduction 

Many of the concepts presented in this section have been taken 
from the thesis of Cdr Robert Wilson [Ref. 28, Ch. 5-6]. 

The purpose of performing a cost effectiveness analysis (CEA) is to 
quantify the costs and effectiveness of network alternatives in a manner 
that allows the alternative with the best overall cost-effectiveness to be 
singled out. 

Cost-effectiveness relates to the measure of a system in terms of 
mission fulfillment (system effectiveness)... True cost-effectiveness is 

impossible to measure since there are many factors that influence the operation 

and support of a system that cannot realistically be quantified ... thus, it is 

common to employ specific cost-effectiveness figures of merit (FOM) ... to 


allow comparison of alternatives on the basis of the relative merits of each. [Ref. 
36, p. 136] 


Detailed definitions for costs and effectiveness will be given in sections 4 
and 5. 

The vast majority of CG telecommunications projects will have 
program costs of less than $30 million. Therefore, these projects will 
normally be categorized as “j III” (Ref. 29, p. 2] under the DOD project 
definitions and “Level IV” under the DOT project definitions. These 
project definitions allow the project managers to choose the tools they 


feel are best to implement a project of this size. 
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Although a CEA is not mandatory, it is a very effective tool and well 
worth the effort required. Application of CEA techniques assists the 


decision makers in quantifying any necessary tradeoffs and permits: 


1. the various parties to a decision to comprehend the basis for 
each other’s conclusions; 


2. decision makers to draw on the intuitions and judgments of 
their staffs without abdicating their decision making 
prerogative; 


3. sensitivity analyses to be made using variations in the 
estimates. [Ref. 30] 


The CG COMDTINST M4150.2D, “Systems Acquisitions Manual,” 
can be a great asset to use while planning and implementing even the 
relatively small Level IV projects. And if unexpected/uncontrollable 
problems crop up, making it impossible to meet schedule, technical, or 
cost projections, it will be reassuring to any project manager to be able to 


demonstrate every effort was made to anticipate problems beforehand. 


2. CEA Overview 

Many methods exist for completing a CEA. Some methods deal 
with the lack of tangible benefits better than others. The multi-attribute 
utility method used here was chosen because it measures system 
effectiveness without having to estimate monetary values for the 
intangible benefits provided by the system. It is very difficult to estimate 
intangible benefits for military telecommunications networks because no 
market value can be affixed to the final product. The essential steps of a 
CEA include: 
define system objective; 
identify essential mission requirements; 


list alternatives; 


= PY 


state evaluation assumptions; 
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establish effectiveness measures; 
evaluate alternatives’ overall effectiveness; 
develop cost data; 


assess effectiveness and cost risks; 


Coon of ul 


perform cost-effectiveness computations; 


10.perform sensitivity analysis. [Ref. 31, 32, 33] 


By using the structured approach model, the first three steps have 
already been accomplished. The next seven sections will deal with the 


remaining steps. 


3. State Evaluation Assumptions 

We do not know every detail of the actual demands that will be 
placed on a telecommunications system. Therefore, in certain areas we 
must make assumptions to fill in the missing details. For instance, do 
we know the actual availability requirements for the system? Generally 
not, but we can assume that anything less than, say, 99% availability 
could seriously lower our mission effectiveness. Anywhere that 
supporting data is not available an assumption must be made. However, 
assumptions should never be made blindly; the attribute should be 
researched and the assumption, along with the reasoning behind the 


conclusion, should be documented. 


4. Establish Effectiveness Measures 
To establish effectiveness measures, first we must define 


effectiveness. Hajek defines effectiveness as: 


...a measure of the probability that the equipment will be ready and 
capable of performing its function and will not experience failure during its 
mission period. [Ref. 34, p. 219] 





The functions that the equipment, or in our case network, is to 
perform have been spelled out in the requirements. We must now define 
what we mean by ready and capable. These are defined by using figures 
of merit (FOM), also referred to as objectives or criterion. For clarity, we 
will stick to FOM. 


a. Figures of Merit 

FOM are typically broad in scope. There are various 
techniques for generating FOM. Keeney and Raiffa [Ref. 35, p. 34] 
suggest starting at the overall objective and then begin asking questions. 
For instance, our overall objective for a telecommunications network 
could be stated as, “our objective is to provide a telecommunications 
network that will meet the users requirements and expectations in the 
most efficient manner possible.” Now, the question would be, “what 
characteristics are necessary to meet our objective?” These 
characteristics, or FOM, would include [Ref. 35 for 1-4]: 

1. Reliability: The probability that a system or product will perform 


in a satisfactory manner for a given period of time when used 
under specified operating conditions; 


2. Maintainability: The ease, accuracy, safety, and economy in the 
performance of maintenance actions; 


3. Manability: The human element and the interface(s) between the 
human and machine; 


4. Supportability: The composite of all considerations necessary to 
assure the effective and economic support of a system 
throughout its programmed life-cycle; 


5. Interoperability: The communications methods between 
machines that provide accurate and reliable access, 
interconnection, and transmission of data without affecting the 
applications that are running. [ Ref. 8, vol. 4, p. F-9] 
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The various FOM will normally influence system 
effectiveness at different levels. To compensate for this, each FOM is 
weighted to equate its contribution. 

By asking the question, “what do we mean by the FOM?,” the 
FOM can be further broken down into more specific, measurable, areas 
known as measures of performance (MOP), sometimes referred to as 


attributes. 


b. Measures of Performance 
A MOP should be both comprehensive and measurable. A 
MOP is comprehensive if, by knowing the level of a MOP in a particular 
situation, the decision maker has a clear understanding of the extent 
that the associated FOM is achieved. A MOP is measurable if it is 
reasonable both (a) to obtain a probability distribution for each 
alternative over the possible levels of the MOP - or in extreme cases to 
assign a point value - and (b) to assess the decision maker’s preferences 
for different possible levels of the MOP. For example, in terms of a utility 
function or in some circumstances, a rank ordering. [Ref. 35, p. 39] 
Let’s take the FOM “maintainability” as an example. What are the 
characteristics? Blanchard and Fabrycky state the most commonly used 
maintainability MOP include: 
1. Mean corrective maintenance time (also known as, mean time to 
repain; 
Mean preventive maintenance time; 
Median active corrective maintenance time; 
Mean active maintenance time; 
Maximum active corrective maintenance time; 


Logistics delay time; 


aaa FS hf 


Administrative delay time; 
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8. Maintenance downtime; 
9. Mean time between Maintenance; 


10. Mean time between replacement. [Ref. 36, p. 375] 


Notice that some of the MOP listed above overlap (i.e., #4 = 
Average[#2 + #3]). The final set of MOP chosen for each FOM, however, 
must be non-redundant. Other desirable properties of the final set 
include complete, operational, minimal, decomposable (for definitions see 
Ref. 35, sec. 2.4.1]. 

Here again, the various MOP will normally affect the FOM at 
different levels. Therefore, each MOP is also weighted to equate its 
contribution to the FOM. 


c. Calculation of Overall Effectiveness 

Now that the FOM and MOP have been defined and assigned 
weights, overall effectiveness can be calculated. Table 11 is an example 
summary table of system effectiveness. Table 2 totals FOM values. 

FOM values and effectiveness are calculated using the 


following equations: 





i 
¥ (MOPiUtility* MOPiWeight) 


I 
(FOMi* FOMiWeight) 
&' 


1 









Effectiveness = 





> (MOPiWeight) 
1 





> (FOM Weight) 
1 


Equation 2: Figure of Merit Calculation Equation 3: Effectiveness Calculation 
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Table 11: MOP Ratings and FOM Expected Values 
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5. Develop Cost Data 

Two of the main factors that affect project costs are the system 
elements (including support) and the project schedule. To provide 
accurate estimations, the system elements must be broken down toa 
detailed level and include the total life-cycle costs. The schedule will 
affect cost estimations depending on the demand it places on resources 


and due to the time-value of money. 


a. Estimating Tools 

Many tools exist that can help us detail both system 
elements and project schedules. Two of the more important tools include 
the Work Breakdown Structure (WBS) and the Program Evaluation and 
Review Technique (PERT). 

The WBS gives us a components view. It is used to break 
complex systems down into subsystem and component levels that can 
more easily be evaluated. A simplified example of a WBS can be seen in 
Figure 22. Each WBS element represents an identifiable item of 
hardware, software, data set, or service [Ref. 37, Encl. 3, p. 2]. Each 
“level” breaks the associated WBS element into smaller, more detailed 


elements. 
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The PERT assists project organizing and estimating from an 


activities perspective. This tool helps us in the following areas: 
1. Define the Activities. Tasks to be performed. 


2. Define Activity Relationships. Identify predecessor/successor 
and lead/lag relationships (finish to start, start to start, and 
finish to finish) among tasks. 


3. Obtain Time Estimates. Estimate the time (duration) 
necessary to perform each activity. 


4. Incorporate External Constraints. Determine schedule 
constraints such as mandatory completion dates, intermediate 
milestone dates, contractual delivery dates, or interfaces with 
other projects. 


5. Incorporate Resources Data. Apply constraints on availability 
or resources such as labor, material, equipment, machines, and 
funds to develop a feasible network that can be achieved within 
resource limitations. 


6. Establish a Baseline Schedule. Assign specific calendar dates 
to activities (and their resources) and issue as a baseline work 
plan. Identify activities on the critical path. The baseline 
schedule must be consistent with the technical and project 
baseline. 


7. Planning the Schedule. The project manager should identify 
and schedule near-term tasks (those to be performed within 12- 
18 months) in more detail and long term tasks ... in lesser 
detail. [Ref. 37, encl. 3, p. 8] 


b. Life-Cycle Costs 

Each alternative’s cost data must be based on its total life- 
cycle costs. As mentioned before, if a telecommunications network is 
planned correctly, there should seldom be a reason to scrap the whole 
thing and replace it all at once. However, the equipment components 
that make up a telecommunications network pass through four stages 
during their life-cycle. These stages, and some of the costs associated 


with the stages, are shown in Table 13. If only a portion of a 
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telecommunications network is being replaced, then only the life-cycle 
costs for the alternative sections need be compared, including those 


costs which vary with each alternative (i.e., support, training, etc.). 


Table 13: Life-Cycle Stages & Cost Elements 


RESEARCH & PRODUCTION & SALVAGE & 
DEVELOPMENT | CONSTRUCTION | OPERATIONS DISPOSAL 


* Planning * Production * Personnel * Inventory Close- 


out 
* Management * Planning * Consumables 


* Shippin 
* Engineering * Management * Facilities Ppmg 


* Data Mgmt 
* Testing * Initial Spares * Support = 


3 — : * Refurbishing 
* Evaluation * Training * Maintenance 


* Equipment * Support Equip. * Shipping "Mises Mian 
* Facilities * Manuals * Technical Data 

* Testing * Supply Mgmt 

* Engineering * Modification 

* Facilities * Training 

* Support Facilities 


* Initial Transport 





c. Present Value Costs 

To complete the CEA, all costs throughout the life-cycle must 
be discounted back to their present values in order to view the 
alternatives on an equivalent basis. The present value of yearly costs 


can be computed using the equation for present value, as shown in 
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Equation 4. A discounted rate of 7%, as set by the Office of Management 
and Budget (OMB) in Circular No. A-94, should be used.5 





a 
(l+r)! 


Where, PV = present value for year t 
F = future value 


PV=F 


r = interest rate 


t = number of years from present 
| 








Equation 4: Present Value Calculation for Year t 


For example, to compute the present value for the costs of a network 


with a 12 year life-cycle, Equation 5 would be used. 










oe eee 
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Where, PV = present value for year t 


F = future value 


r = interest rate (0.07) 





Equation 5S: Example Equation for 12 Year Life-Cycle 


While determining the life-cycle costs, we should try to be as 
thorough as possible; however, we must also take care not to include 


redundant costs in more than one category. 


d. Estimating Pitfalls 
Once the estimating process is about complete, project 


managers, even seasoned managers with a few projects under their belts, 





5 This discount rate was last updated January, 1995. It is revised when significant changes in 
interest rates occur. 
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should take the time to review the estimating process. Hajek’s list of cost 
estimating pitfalls to avoid is shown in Figure 22. 
Cost Estimating Pitfalls 


1. Omissions: Was any significant cost element forgotten? For instance, are 
there any bench checks planned and does the estimate include the 
engineering, material, and other costs for such effort? 


2. Inaccuracy of the work breakdown: Does the work breakdown adequately 
account for all the subsystems and efforts required of the device? 


3. Misinterpretation of the equipment data or function: Is the interpretation of 
the complexity of the device accurate? Interpretations leading to excesses 
of complexity, or simplicity, will result in estimates that are either too high 
or too low. 


4. Use of wrong estimating techniques: The correct estimating techniques must 
be applied to the device in question. For instance, the use of cost statistics 
derived from production runs of a similar subsystem and using such figures 
for a prototype device which requires engineering and/or development will 
invariably lead to excessively low estimates. 


5. Failure to identify and concentrate on major cost elements: It has been 
statistically established that for any piece of equipment (or system), 20 
percent of the subsystems will account for 80 percent of the total cost 

(Pareto’s Law of Distribution). The point is that project engineers should 

| concentrate their time and effort on the high-cost subsystems in order to 

enhance their chances for establishing an accurate cost estimate. 





6. Failure to assess and provide for risks: By its nature a prototype device 
involves engineering and design effort that must be breadboarded and 
bench tested for verification. Such tests usually involve an expenditure of 
effort to redesign and refine. 








Figure 23: Cost Estimating Pitfalls [Ref. 34, p. 62] 
(i) 
6. Risk Assessment 
Proper project management requires that we evaluate what impact 
our decisions may have on increasing or decreasing the chance, or risk, 


that future problems will occur. This section will discuss the different 


perspectives of risks, the elements of risk, and the analysis of risk. 
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a. The Three Perspectives of Risk 
There are three perspectives to risk, all of which must be 
considered to fully comprehend the effects an element of risk may have 


on a project. The three perspectives are: 


1. potential magnitude of loss (how much we may lose); 

2. chance of loss (probability of a loss occurring); 

3. exposure to loss (how much can we afford to lose). [Ref. 38, p. 
24] 

For instance, suppose we identify the schedule for 
microwave installation as containing an element of risk. If we stay with 
the currently planned installation crews, there is a chance that the 
schedule could be affected by winter weather. If we increase the crew 
size, project costs will increase. We must consider it from the three 
perspectives: 1) how much time may we lose?, 2) what chance is there 
the schedule will be delayed (very slim/very great)?, 3) if the loss occurs, 
can we afford it? If any of the three components are at levels that cannot 


be accepted, we must find a way to decrease the risk. 


b. The Elements of Risk 

The Defense Management Systems College Publication, “Risk 
Management, Concepts, and Guidance,” identifies five elements of risk: 
Cost, Schedule, Technical Performance, Programmatic, and 
Supportability. The first three are defined as basic elements. Table 14 
contains some of the sources for the five risk element. Each of the 


applicable elements should be evaluated using the three perspectives. 


c. Risk Analysis 


Risk analysis must be completed for both life-cycle costs and 


effectiveness values. 
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During this phase of the project (alternative selection), the 
risks affecting life-cycle costs should be estimated in dollars for 
comparison purposes. The affects of these risks can normally be 
estimated in either personnel or equipment costs. With a little effort, 
these can be culminated into a final monetary estimation. These costs 


are normally stated with a plus/minus percentage, where the value falls 


within two sigma (95% confidence interval). 





Table 14: Sample Risks by Element 
Typical Technical 


Risk Sources 








Physical properties > 
Material Properties 
Radiation Properties 
Testing/ Modeling 
Integration/ Interface 
Software Design 

Safety 

Requirement Changes 
Fault Detection 
Operating Environment 


Proven/Unproved 
Technology 


System Complexity 


Unique/ Special 
Resources 


Typical 
Programmatic 
Risk Sources 





Material Availability 
Personnel Availability 
Personnel Skills 
Safety 

Environmental Impact 


Communication 
Problems 


Labor Problems 
Requirement Changes 
Political Advocacy 
Contractor Stability 
Funding Profile 
Regulatory Changes 


Reliability & 


Typical” 
Supportability 
Sources 





Maintainability 


Training & Training 
Equip. 


Operation & Support 
Equip. 


Manpower 
Considerations 


Facility Considerations 


Interoperability 
Considerations 


Transportability 
System Safety 
Technical Data 


Computer Resources 
Support 


Supply Support 


Maintenance Concept 
Changes 





| Typical Cost Risk 


Sources 


| Sensitivity tor 
Technical Risk 
Programmatic Risk 
Supportability Risk 
Schedule Risk 

Overhead /G&A Rates 


Estimating Error 


Typical Schedule 


Risk Sources 





Sensitivity to: 


Technical Risk 

Programmatic Risk 

Supportability Risk 
Degree of Concurrence 


Number of Critical Path 
Items 


Estimating Error 
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Analyzing risks on the effectiveness side, and then 
converting them into monetary values, or other scaleable values, is a 
different story. In some cases, with a lot of work, experience, and skill, 
this is may be possible; however, in most cases it is not. The very act of 
converting these estimated risk values into a single value suggests a 
much higher level of accuracy than is available. suppose an analysis has 
been completed and the risk converted into a value of $48,000 + 20%. 


Once given to the decision-makers, the first questions asked will include: 
1. what is the basis for these values? 


2. What certainties are the estimates based on? What 
uncertainties? 


3. Has the methodology used been proven accurate in the past? 
How accurate? Were the conditions similar? 


These are difficult questions to answer, let alone defend; but 
if a decision-maker is going to make informed decisions and be held 
accountable for these decisions, they need to understand where the 
figures came from. 

Another alternative, as explained by Dr. James Emery®, 
appears to be much more appropriate, as well as convenient. He states 
that if the decision-makers are going to make the decisions, their real 
need is the information on which to base those decisions. He suggests 
documenting the applicable information in a concise paragraph form, 
along with the analyst’s perspective of the situation. In this manner, the 
decision-makers are supplied with all the pertinent data and can decide 


for themselves what the possible levels of risk will be. 





6 As per conversation with Professor Emery on December 6, 1995. 
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7. Cost Effectiveness Computations 
Once the effectiveness, life-cycle costs, and monetary risk values 
have been calculated, a cost-effectiveness summary table can be formed. 


Table 15 is an example of such a table. 


Table 15: Cost Effectiveness Summary Table 


Alternative # 1 Alternative #2 





Overall Effectiveness 





Life-Cycle Costs ($K) 





Cost Risk 











8. Sensitivity Analysis 

Suppose the analyst has completed a CEA and the final numbers 
show alternate “X” to be the most cost-efficient. To complete this CEA, 
we have had to make assumptions, estimate costs, estimate usage, and 
make a host of other educated guesses, all of which affect the outcome of 
the final numbers. 

The purpose of the sensitivity analysis is to help us understand 
just how sensitive our final numbers are to relatively small changes in 
our assumptions and estimates. To measure sensitivity, normally only 
one variable is changed at a time and the effects measured and recorded; 
however, if a variable that has other variables dependent on it is 
changed, then all of the dependent variable values should be changed as 
well. For example, if “per hour” leased-line charges vary with usage, then 
the values for both usage and “per hour charges” should be varied at the 
same time. Sensitivity analyses can be used to measure the effects of 


both controllable and uncontrollable input variables. 
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With the advent of modern spreadsheet products, a sensitivity 
analysis can be completed very quickly. It is recommended that all CEA 


computations be completed using a worksheet application. 


D. THE BACS MIGRATION 

With the wide range of site types, site locations, site 
telecommunications requirements, and the like, the final network will 
most likely use several types of transmission media. For example, some 
sites already have leased lines installed. The requirements for some of 
these sites will never rise above the service already provided. Therefore, 
there is no reason to replace these links with different technology. 

On the other hand, some remote sites now operating over 
microwave require redundancy. Even if microwave is found to be the 
most cost-efficient technology for these sites, a secondary technology will 
likely be required for the redundancy. This example shows the extent to 
which the standards, applications, and components chosen must be kept 
vendor and technology-independent for as long as possible. 

The biggest challenge with using a CEA with the BACS project 
could possibly be limiting the number of alternative migration candidates 
to be considered. The project managers must find a method to limit 
candidates without excluding those that could end up being the best 


alternatives. 


E. CONCLUSION 

The CEA is a very useful tool. It provides the organizational 
procedures to insure that our estimations are as concise as possible. 
One must remember, however, that it is only a tool; and the quality of 
the final product depends as much on the craftsman and the material 


(data) used, as it does on the tool. 
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VIII. SUMMARY 


Before summarizing the phases discussed in this paper, let’s 
discuss the last two phases, “Implement System Plan,” and “Maintain 
System Process.” By excluding them from the content of this paper in no 
way suggests they are less important than the others. In fact, the first 
six phases only build the solid foundation on which the actual project, 
contained in the last two phases, is built. 

The procedures used during the Implement System Plan phase will 
vary greatly depending on the cost, schedule, type of contract, and many 
other variables. However, if the previous five phases have been 
completed judiciously, the project officer should be aware of all the 
processes necessary for a successful implementation. The last phase, 
“Maintain System Process,” adds an additional dimension in which the 
CG has not operated in the past. There are two main themes behind this 
phase. One is to continue the migration process, upgrading the 
architecture as necessary. It is only due to the recent advances in 
technology that we are now able to incrementally upgrade networks. The 
second theme is based on periodically re-evaluating the network. The 
TAFIM emphasizes that this should be done by reiterating the other six 
phases of the model. 

Although the procedures in this paper are laid out in a 1-2-3 
fashion, it should be understood that numerous iterations of portions of 
the model may be necessary before reaching a level of acceptance by all 
parties involved. Although this can be time consuming and must be 


limited in some manner, it does lead to a better designed product. 
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The BACS Replacement Project is relatively simple from a 
technological view. However, from a functional or organizational 
perspective, the project will be very complex. Gathering, evaluating, and 
tracking the functional requirements of at least 11 different entities 
located at 18 different sites will not be easy. This provides the design 
team with a great temptation to aggregate details to simplify the problem. 
By using the Structured Approach Model, the design team will be 
encouraged to view the project from various perspectives and use either 
the procedures suggested in this paper, or alternative methods for 
tracking and documenting all the pertinent details. 

For an organization to become more efficient and effective as a 
whole, it must learn to apply systems thinking. Procedures and reward 
systems must be changed to encourage individuals to plan for efficiency 
and effectiveness on the organizational level, rather than the department, 
division, or command level. 

The Structured Approach Model is one method for applying 
systems thinking to project management. It ensures that the project is 
planned on an organizational level, taking into account the requirements 
and resources of all the entities involved. By examining each of the 
seven phases from the functional, organizational, and physical views, the 
prospect that important details will be overlooked greatly decreases. By 
investing the additional time up front necessary to apply the Structured 
Approach Model, the project team will be steered towards a network that 
will benefit the total organization. The network itself will be designed for 
greater interoperability, supportability, as well as cost and technical 
performance. 

The Coast Guard must have an effective, interoperable 
telecommunications backbone if its overall efficiency and effectiveness is 


to increase. 
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GLOSSARY 


Access control server - The access control server maintains the 
access control lists for each object within the technical 
environment. The access control server determines whether access 
to the requested system object is authorized. 


Applications server - An application server provides a set of standard 
application services to clients. It is a form of packaging an 


application as a commonly used and reusable component of the 
infrastructure. 


Authentication server - Validation of users, nodes, programs, and 
other required objects is performed through the authentication 
server. Secure channels using encryption and/or some form of 


trusted communications provide the linkage between client and 
server. 


Batch processing - Batch processing environments are characterized 
by their ability to queue work (jobs) and manage the sequencing of 
processing based on job control commands and lists of input data. 
The results of this processing include updated information files or 
databases and often printed reports or special forms that are 
themselves queued as output jobs. 


Broadcast - Broadcasting environments provide one-way audio or 
audio/video communications between a sending location and 
multiple receiving locations. They include the use of private TV 
facilities that can be purchased or leased for corporate purposes. 
Many organizations are taking advantage of these facilities and 
offsetting travel costs for use in corporate announcements and 
product introductions. 


Communications management services - Communications 
management services is another GTE that is used by all of the 
other GTE that want to communicate. This environment 
implements the communications infrastructure consisting of 
various communication servers, name and directory services for 
resolving addresses, and authentication and access control for 
ensuring the appropriate level of security. Thus, all the technology 
associated with communications and connectivity is bundled into 
this environment. 
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Communications server - The communications server forms the 
basis of managing connections between objects in the 
environment. It provides connections between objects independent 
of the physical implementation of the network and ensures 
accurate delivery of messages between objects. 


Computer conferencing - Computer conferencing environments 
combine the merits of document creation, E-mail, and 
conferencing by allowing groups and subgroups to participate in 
“conferences” via computer workstation. These conferences, 
however, do not occur in real time. The conferees discuss 
proposed topics through interacting over time. Conferees, or 
invited guests, can drop in or out of conferences or subconferences 
at will. The ability to trace the exchanges is provided. 


Conferencing management services - Conferencing Management 
Services supports the real-time exchange of information from one 
or more user clients. It permits a user to address a 
communication to any member of a group without needing to know 
exactly who is in the group receive communications from all or 
selected members of the group without needing to know who is 
currently in the group, and to reply to them in a like manner. 


Cryptographic server - Encryption services for any process are 
provided by the cryptographic server. The cryptographic server 
also manages keys and handles distribution of valid keys among 
the cryptographic servers. A centralized key management server 
may be required. 


Data server - The data server provides data services to clients. A 
client will send a request to a data server (sometimes called a 
database server) and the server will respond with the results of the 
request. The accessing and updating of the data maintained on 
the data server is performed by the data server, not by the clients. 


Database management services - Database management services 
consist of the servers required for managing files and data within 
the technology environment. It consists of data servers that 
implement databases and file servers that provide local and remote 
access to various types of files. 


Decision support - Decision support environments provide 
interactive modeling and simulation tools that allow the user to 
analyze the effects of alternative decisions. These modeling and 
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simulation tools typically work in conjunction with files and 
databases that were created from batch or transaction processing 
environments. 


Desktop or Portable Intelligent Workstations - These serve single 


users and provide personal computing services and access to 
network(s). 


Development services - Development services provide support for all 
aspects of systems delivery including all phases of the development 
life-cycle, prototyping, and end user development. This 
environment interacts with the other GTE to access information on 
the current infrastructure and to implement changes and 
enhancements. 


Directory server - The directory server provides a means of finding a 
set of entity attributes based on qualifiers, such as a telephone 
number or other descriptive characteristic. Unlike a name server, 


the searches are often ambiguous and based on a combination of 
attributes. 


Distribution management services - Distribution management 
services support the distribution of messages, transactions, files, 
and any other information between technology environments and 
physical locations. This environment consists of servers that 
implement electronic mail, voice mail, and EDI. It also is tightly 
linked to the communications management services GTE to 
provide the actual communications between components. 


Divisional or Departmental Processing Systems - These provide, 
primarily local users, on-line transaction processing services. 


Document management services - Document management services 
are analogous to information management services, providing 
other environments with the means to access and manipulate 
documents—either text only or some combination of data, text, 
voice, graphics, and image (a compound document). The key 
difference between these two technology environments today is the 
level at which we can manipulate basic elements of information. In 
information management services, we can access and manipulate 
each field within the file or database. In document management 
services, we generally access the entire file or document using 
application specific formats for manipulating portions of the 
document. For example, the format for a Microsoft Word 
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document is different from WordPerfect; likewise, the way graphics 
is stored in each differs. 


Document processing - Document processing environments extend 
the basic capabilities of text processing to take advantage of the 
graphics capabilities of today’s workstations and laser printers. 
Consequently, they provide powerful document and presentation 
tools for the end user. 


Document storage & retrieval - Document storage and retrieval 
environments are used to retain large volumes of stored 
information in document formats. Originally these systems were 
based on microfilm media using film or fiche with special readers 
to magnify the information. Computer output microfilm (COM) 
systems are used to store computer-generated listings or reports. 


EDI translation server - The EDI translation server interprets the 
content of EDI messages and routes them to the appropriate EDI 
partners. The EDI server works hand in hand with the mail server 
but needs to interpret the EDI message to translate it or route it to 
the correct recipient. 


Electronic mail - Electronic mail environments support the storage 
and forwarding of directed messages, mail, and other documents 
or files between sender and one or more recipients. They provide 
the sender with facilities to create or define the message(s) or file(s) 
to be sent, use directories and distribution lists for routing 
information, assign priorities, use pre-formatted electronic forms, 
and trace the status of messages sent. 


Electronic publishing - Electronic publishing environments extend 
document creation and production tools to provide formal 
publishing capabilities. This includes incorporation of 
photographic quality images and color graphics, very advanced 
formatting and style features, such as wrapping text around 
graphic objects or pictures, and kerning (overlapping characters to 
optimize spacing). 


Enhanced telephony - Enhanced telephony environments provide 
improved means of using the phone system for interactive audio 
exchanges between users. Features include call forwarding, call 
waiting, programmed directories, teleconferencing capability, 
automatic call distribution (useful for busy customer service 
areas), and call detail recording. 
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Enterprise or Corporate Processing Systems - These serve a large 
base of networked users with on-line and batch processing 
services. 


Establishment-based Switching Systems - Premise-based switching 
services Gateways to WAN Associated servers (e.g., IVR, V-Mail). 


Expert systems - Expert systems environments use a type of artificial 
intelligence built with inference engines and knowledge or rule 
bases that take or recommend actions based on presented 
situations and past “experience.” They are used to augment 
human decision-making processes where the “expertise” or 
thought processes of the decision maker can be defined as rules. 


File server - The file server provides transparent access to files from 
workstations and other clients. Unlike a data server, the file server 
provides access and linkages to the file directories and is not aware 
of the contents of the file. Processing of contents of a file needs to 
be performed by the client. The file server does no client-visible 
manipulation of the data within a file. Essentially, the file server 
provides the client with the use of a virtual disk drive and little 
else. For example, in a workstation environment, the workstation 
would perform all the processing on the file. 


Hypermedia - An emerging area for information management is 
hypermedia. Hypermedia provides a highly flexible way of linking 
objects. Over time, documents, images, and other objects could be 
linked in hypermedia databases resulting in the elimination of 
document management services as a separate entity. 


Hypermedia processing - Hypermedia processing is a new 
environment that extends the object-oriented approach to 
organizing and displaying information by utilizing various 
relationships between the stored or created objects. As such, it 
overcomes the limitation of the printed page and allows the user to 
“navigate” through the compiled information based on mixed form 
objects in a manner that is consistent with the needs and 
capabilities of the user, not some fixed presentation format. 


Inquiry processing - Inquiry processing environments support 
functional area activities requiring interactive selection, extraction, 
and formatting of stored information from files and databases. 
They are used in conjunction with batch and transaction 
processing environments to provide information retrieval using 
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either structured (routine) or ad hoc (definable) queries. They are 
intended to replace the need for extensive reporting systems by 
providing only needed information on demand. 


Intelligent Wide Area Network Systems - A WAN system capable of 
providing value-added WAN switching services, transparent access 
to servers, and WAN management. 


Local Area Network Systems (LAN’s)- LAN’s connect file servers and 
device servers and provide for local transport and resource 
sharing. 


Mail server - The mail server provides mail transfer capabilities for a 
community of users. The basic function is to support the store 
and forward of interpersonal messages between users. The mail 
server moves messages based on the contents of the message 
envelope not the message’s contents. 


Name server - The name server provides a means of finding an 
attribute of an entity given the unique name for any entity within 
the technology environment. Entities can be physical components 
(computers, workstations, network nodes), logical components 
(application modules, data storage locations), or users. 


Presentation server - The presentation server provides presentation 
services for a client application and/or a person. It creates a 
generic presentation environment that is independent of the 
underlying technology and provides a means for users to interact 
with the technology environment. 


Print server - The print server provides common printing services to 
clients within the environment. The print server provides 
transparency between the client and the physical printer. For 
example, differences between different vendors’ laser printers 
should be transparent to the client. 


Real-time control - Real-time control environments support event- 
driven processes supporting monitoring and actuation of physical 
processes. For this reason, they are often referred to as sensor- 
based systems. They are designed to handle and process 
interrupts from a variety of sources (typically involving some kind 
of sensor device or timer), process associated information through 
some type of capture or control algorithm, and respond, if 
necessary, with an appropriate signal to a control or actuation 
device. 
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Repositories for system construction - A passive repository, such 
as those being introduced by IBM, DEC, and others, can provide 
the dictionaries and system encyclopedias needed for defining and 
constructing application systems and data. This type of repository 
is the essential underpinning of a CASE environment, as it 
provides the basis for storing information at each phase in the 
development cycle and transferring that information from one 
phase to another. 


Repositories for systems management - Another type of repository, 
called the active repository, can be used to store system 
information and to dynamically manage the IT environment. For 
example, with the capabilities of an active repository, system 
management services could manage the execution of applications 
to optimize performance and reliability. 


Repository services - Repository services is an emerging GTE that 
will provide the repository environment for managing the 
technology environment and the applications and data stored in 
the environment. The repository can store information about any 
“object” in the technology environment including, but not limited 
to, the physical processors, application modules, data, and 
processing functions. All of the GAE, GTE, components, and 
servers defined in this document would be entities in a repository. 


Sensor monitor/actuator server - The sensor monitor/ actuator 
server provides client applications and users with an interface to 
physical devices such as cash dispensers, building monitoring 
systems, or any other device that interacts with physical control 
systems. 


Shared screen teleconferencing - Shared screen teleconferencing 
environments are another newly emerging type of system aimed at 
supporting more effective remote communications in an interactive 
mode between two or more users. They combine an audio 
teleconferencing capability with shared common workstation 
“windows” that are refreshed on every conferee’s workstation 


whenever someone displays new material or changes an existing 
display. 


System management services - System management services 
support all activities dealing with the management of the 
computing environment, interacting with all other GTE to provide 
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the management capability to monitor and control the total 
environment. 


“T” or “t” - Designation used to represent the Coast Guard’s 


Command, Control, and Communications community. Capital t 
represents headquarters staff, while the small t represents “t” 
personnel assigned to other commands. 


Text processing - Text processing environments support the creation 


of text documents. They have evolved from the early word 
processing systems of the seventies to be popularized as part of the 
explosive application growth of desktop personal computers. They 
offer greatly improved editing and revision capabilities over the 
typewriters that they were designed to replace. 


Time server - A critical need in distributed environments is to make 


sure that time is synchronized throughout the environment. This 
is especially important in distributed transaction processing 
applications and database environments where logs need to be 
kept synchronized to support transaction backout and recovery. 


Transaction media services - Transaction management services 


implement the environment required for managing transaction 
processing. This environment includes the basic functionality and 
servers required to implement a transaction processing 
application. In today’s world, CICS would fit under transaction 
management services. In the future, it is anticipated that a 
client/server environment will become the norm. 


Transaction processing - Transaction processing environments 


support on-line capture and processing of information in an 
interactive exchange with the user. These typically involve 
predetermined sequences of data entry, validation, display, and 
update or inquiry against a file or database. 


User interface services - User interface services provide the basic 


means for users to interact with the computing environment, 
managing the user interface for any class of user interface device 
from a simple character terminal to an advanced graphic 
workstation. User interface services also provide support for the 
user in navigating through to the appropriate system or server, 
authenticating the user and managing the user’s desktop. 


Video processing - Video processing environments support the 


creation of video “productions,” either as sequential presentations 
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or as interactive presentations, under user control. They involve 
both video and sound capture and editing, as well as incorporating 
still graphics and title generation capabilities. 


Video teleconferencing - Video teleconferencing extends the remote 
meeting environment to include full motion display of events and 
participants in a bi-directional manner. Thus, the facial 
expressions and body language of presenters and questioners is 
displayable to all participants in a conference. 


Voice mail - Voice mail environments offer the storage and 
forwarding of voice messages for a designated set of recipients. 
They are usually used as an extension of the phone system to 
provide an alternate to message centers. They typically allow the 
recipient to retrieve recorded messages remotely from any touch- 
tone telephone. 
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APPENDIX A: 


BACS SITE LOCATION CHART 
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APPENDIX B: 


SYSTEM FUNCTIONALITY 
BLOCK DIAGRAMS 


149 


COAST GUARD 


ppt tan 





Sa 
WORKSTATION == — 








7 
| 
| 
| 
{ 
| 
| 
| 
| 
i 


D.P. CONSOLE wom MODEM oy 


DATA NETWORK 





MICROWAVE 
ANTENNA © 





em DP CONSOLE ey 
WORKSTATION i MICRO XCVR 


4 


! MICROWAVE _- 





| 
i 
| 
| 
te 











= , 


WORKSTATION 


| 

= 
| . | 
! 
\ 





DISTRICT 11 


150 





= 


| 
| ANTENNAS 
1H Jt roa 





_ MICRO REPEATER _ _ 
— HIGH SITE 





[FUSE OCP SO TES eee RESETS STS as STD ee SETS 


VHF-FM (VOICE) VESSEL 
TRAFFIC SYSTEM (VTS)/ 
NATIONAL DISTRESS 
SYSTEM (NDS) 


STATION / GROUP SAN | FRANCISCO & COAST GUARD ISLAND 











a” Ig D.P. CONSOLE MICROWAVE XCVR 






 VHF-FM CH 16 GUARD (VOICE) 
| 


HIGH/ NAVAID END SITE ; ° 





‘oa MICROWAVE 
“ee 
((W ») — was 
ie XCVR 


VHF ANTENNA |. _ ~~ ere - 








AIR CONTROL 
UHF VOICE/DATA 








"AFSO 







MICROWAVE 
ANTENNA 
































& SPEAKER 
‘MTAM | 
| MICROWAVE MICROPHONE | 
= 4 & SPEAKER 
{ Kor wn . 
a : iv ( 
| = oT} “ : 
UHF MICROWAVE 








XCVR RCVR 





HELICOPTER 





152 


HSTN / HDN 


MICROWAVE 
ANTENNA _ 


Se. 


MICROWAVE 
NTENNA 








MICROWAVE | 
XCVR A 





153 


CGI PHONE 


(TELEPHONE PBX) 
MICROWAVE ANTENNA 





MISCELLANEOUS. SYSTEM 
(HF, Video, Radar, CAMSPAC 
Link and Alarms) 








4 HF CONTROLS 
& ANTENNA ANTENN 
{ } a 
DATA ==>} RADAR 
nena amano ae i we CONTROLS 
Ai ae Tae wes “ae ao 
RADAR CONTROL <= ¥ oaslepreesy 
ALARMS | 
| 
RADAR 
a. 
—... 








| Seale 
VIDEO CAMERA | Witiaeleenctcis ‘a 
TV MONITOR 





155 


GROUP S. F. & C.G. ISLAND 


; \ DISTRICT ly! 


hacia ANTENNA 





| | 


Gis HF XCVR 
aaa CONTROLS 


HF VOICE & 
ial MICROPHONE 


Nene ecto HF-FM VOICE & 
CNECT & BRIDGE MICROPHONE 


Je 


UHF VOICE & 
MICROPHONE. 
















PACAREA INTEL  HSTNQHDN) | APARMS (ACMS) 





FTS LANDLINE TELEPHONE TELEPHONE 
PBX SYSTEM pBYX SYSTEM 
fl SWITCH 


& 





? 
_” \/HE-FM VOICE 
| acme GUARD CH. 13 &16 





i} 





PSTN LAND LINE 


156 


STATION 





MICROWAVE 
ANTENNA 
RADAR 
CONTROLS 
LT HOUSE 
GENERATOR 
ALARM Ae 
UHF MICROPHONE 





(VOICE) 





J 


VHF-FM (VOICE) 









D.P. CONSOLE 
MODEM & TERM CARD 





VHE-FM CH 13 & 16 GUARD 
(VOICE) fF F 
Sete PBX 
RENAE ER IRA ! ‘ SYSTEM pag ry 
'FTS LAND LINE | om — (8 
' TL LINE | ao | | 
TO/FM a 
NAVAID 7 TV MONITOR 
wal ) END RADAR tennce | | 
| PSTN LAND LINE 1 DATA 
i. Sacer TV CONTROL 





157 





RELAY HIGH 
SITE 


RECEIVE MICROWAVE 
ANTENNA 


XMIT MICROWAVE 
PBX SyvsSroum ANTENNA 






MICROWAVE 
XCNECT & REPEATER 


wy 7 | 4 cote 








Sige 


VHF ANTENNA & XCVR UHF XCVR & ANTENNA 


af PSTN LAND LINE | 


158 


NAVAID/END SITE 

| 

x | 
| 


| TV CAMERA 
& CONTROL 
MONITOR 
t 
{ 
i 





; & . | Pa ee 
> -RADSE CONTRO! i P w aan 
j iV; oe pe 
veo . =| a ee 
| MICROWAVE ANTENNA & XCVR eee 
T-1 LAND LINE 2 an a i 
FM/TO VTS YERBA : : 
BUENA ISLAND ‘ , 4 1 
ce TELEPHONE 


HF XCVR VHF XCVR UHF XCVR PBX SYSTEM 


i 


(Gq) (Ws »))) (( »)) 
1° 7K? OK 


HF VHF 
ANTENNA ANTENNA 


159 


160 


A 


OV 


10 


12 


13 


14 


15 


16 


17 


18 


19 


LIST OF REFERENCES 


Coast Guard District Twelve (otm) letter 2800 of 23 June 1983. 
MLCP (tts-2) Funding Request dated 31 March 1994. 


anes. P.M. [et al.], The Fifth Discipline Fieldbook, Doubleday, 
1994. 


Webster’s Ninth Collegiate Dictionary, Merriam-Webster Inc., 1984. 


Naval Command, Control and Ocean Surveillance Center, United 
States Coast Guard Bay Area Communications System Base 
Electronics Systems Engineering Plan (BESEP), 1995. 


Senge, P.M., The Fifth Discipline, Currency Doubleday, 1994. 


Conversation with MLCP project officer, Mr. Gerry Busch, June, 
1995. 


Defense Information Systems Agency, Technical Architecture 
Framework for Information Management (TAFIM), Volume 1, 
Overview, Version 2.0, Defense Information Systems Agency for 
cea Department of Defense, Washington D.C., November 
1, 1993. 


Logan, Paul, R., A Structured Approach to Information Technology 
Management in the Department of Perens, .S. Thesis, Naval 
Postgraduate School, Monterey, California, September, 1994 


COMDTINST 16010.12, Commandant’s Direction, Commandant (G- 
CX), 2100 Second St. S.W., Washington D.C., 1995. 


Jones, Carl R., Information Technology Management in the 
Department of Defense, Module 3, Su module B, Class Notes, 
Naval Postgraduate School, Monterey, California. December 4, 
1993. 


U.S. Coast Guard ALCOAST 097/95, COMDTNOTE 7100, Coast 
Guard Streamlining Plan, Commandant (G-C), 2100 Second St. 
S.W., Washington D.C., October 16, 1995. 


G-T INSTRUCTION M5S000.1A, Project Management, Office of 
Command, Control, and Communications, , Commandant (G-TT), 
2100 Second St. S.W., Washington D.C., January, 1991. 


Angelakos, D. J., Everhart, T. E., Microwave Communications, 
McGraw-Hill Book Co., 1980. 


Pe J. J., Digital Communications by Satellite, Printice Hall, 
1985. 


Suh, Myung, notes from IS3502: Computer Networks: Wide Area & 
Local Area, Spring Quarter, 1994. 


Reeves, Jonathan, Frame-based Interface Will Ease ATM Access, 
NetworkWorld, May 08, 1995. 


Wiedenhoeft, Paul, An Analysis of a Microwave Link, November, 
1993. 


Dudzinsky, S. J., Atmospheric Effects on Terrestrial mm-Wave 
Communication, Microwave Journal, 1975. 


161 


20 


21 


22 


23 


24 


25 


26 


27 


28 


29 


30 


31 


32 


33 


34 


35 


36 


37 


38 


Hogg, D. C., Millimeter-Wave Communication through the 
Atmosphere, Science Volume 159, Number 3810, 1968. 


Haber, F., Interference Analysis and Prediction, Microwave Journal, 
July, 1975. 


Katayama, M., Morinaga, N., A Study of the Communication 
Systems Using the Low-altitude Nongeostationary Satellites, IEEE 
Communications Journal, 1993. 


Taner, Herbert A., Naval Postgraduate School lecture, March, 


American Mobile Satellite Corporation presentation package, 
Getting Mobile Satellite Communications off the Ground. 


Taff, Anita, Public Networks Boast New Data Services, Federal 
Networks, May, 1994. 


ick Angela, Connecting Over the Airwaves, PC Magazine, August, 
1 : 


Emery, James C., Management Information Systems, Oxford 
University Press, 1987. 


Wilson, Robert J., Decision-Making Guide for the Proposed Coast 
Guard Differential Gobal pbiee A System, Master’s Thesis, Naval 
Postgraduate School, Monterey, CA, June, 1991 


DODI 5000.2, Major Automated Information System Acquisition 
Programs, November, 1995. 


Archibald, R.D., and Villoria, R.L., Network-Based Management 
Systems (PERT/ CPM), Wiley, New York, 1967. 


Kavvadias, B., Telecommunications Systems Cost-Effectiveness 


Analysis - A Quick and Practical Approach, class paper for Professor 
W.R. Gates, CM 4003, March, 1989. 


Joint Tactical Communication Office, Fort Mommouth, NJ, Cost- 
Eo epuoetess Program Plan for Joint Tactical Communications - Life- 
ycle Costing, version II, 1982. 


Seiler, K. III, Introduction to Systems Cost-Effectiveness, Wiley- 
Interscience, 1968. 


Hajek, Victor, Management of Engineering Projects, 2nd edition, 
Macrame ill, 1977. ve =e 


Keeney, Ralph L., and Raiffa, Howard, Decisions with Multiple 
Objectives, John Wiley & Sons Inc., 1976. 


Blanchard, Benjamin S., Fabrycky, Wolter J., Systems Engineering 
and Analysis, Printice-Hall Inc., 1981. 


U.S. Coast Guard COMDTINST M4150.2D, Systems Acquisitions 
Manual, December, 1994. 


Olson, David L., Courtney, James F., Decision Support Models and 
Expert Systems, Macmillan Publishing Co., 1992. 


162 


INITIAL DISTRIBUTION LIST 


. Defense Technical Information Center 


Cameron Station 
Alexandria, VA 22304-6145 


. Library, Code 52 
Naval Postgraduate School 
Monterey, CA 93943-5002 


. Commanding Officer 
USCG TISCOM 

7323 Telegraph Rd. 

’ Alexandria, VA 22315 


. Professor James Emery, AS/Ey 
Naval Postgraduate School 
Monterey, CA 93943-5000 


. Professor Frank Barrett, AS/Br 
Naval Postgraduate School 
Monterey, CA 93943-5000 


. CDR (Ret.) Rex Buddenburg, AS/Bu 


Naval Postgraduate School 
Monterey, CA 93943-5000 


. Commandant 

2100 2nd St. S.W. 
Washington, D.C. 20593-001 
Attn: CG Library 


. Commanding Officer 
USCG TISCOM 

7323 Telegraph Rd. 
Alexandria, VA 22315 
ATTN: LT L. Stone 


. SUPERINTENDENT 


U.S. Coast Guard Academy 
15 Mohegan Ave. 

New London, CT 06320-4195 
ATTN: CAPT Peterson 


163 





No. Copies 
2 


10.Commanding Officer 
USCG EECEN 
PO BOX 60 
Wildwood, NJ 08260-0060 


164 


DUDLEY KNOX LIBRARY 
NAVAL POSTGRADUATE SCHOOL 
MONTEREY CA 92353-5104 





DUDLEY KNOX LIBRARY 


OO il 





